В примере падение происходит в строке Mockito.when(null).thenReturn("qwerty"); - в момент настройки (когда история вызовов пустая), а не в момент использования.
Возможно, так проще
@Test
public void testFailed() {
Object mockObject = Mockito.mock(Object.class);
//mockObject.toString(); // если раскомментить, ошибки не будет
Mockito.when(null) // тут падение
.thenReturn("qwerty");
Assertions.assertEquals("qwerty", mockObject.toString());
}
Общебанковские сообщества - первый движ направленный на выравнивание инженерных практик, который не вызывает отторжения. Поголовные DevOps, t-shape, платформы - все насаждалось. Ни кто не знает как правильно, ничего не работает, но НАДО, а потом переделать (намерения всегда благие, но вот исполнение и реакция...). А тут прям бальзам на душу. Хочешь - участвуй! У нас есть готовые решения, приходи и бери. Костылируй сам, ищи единомышленников, публикуй решения для остальных не в пределах своего трайба или направления, а на всех разрабов. А не хочешь - просто не делай.
В статье количество схем в пуле 10, без проблем сделать больше, просто этого хватает. В бою (не для статьи) используется не по 1 схеме на тест, а по несклько — в метаданных перечисляются схемы с разными префиксами, но одинаковыми id-суффиксами: Схема на заполнение БД и схема "пользователя без таблиц", куда только гранты на чтение выдаются.
Запускать параллельно тесты в рамках одной сборки — потратить время на создание структуры через liquibase, это накладнее по производительности. Сейчас по производительности бьет халатное отношение к ней. Если мне надо протестировать запрос на 1000 записей, у меня будет 1000 операций вставки. Объединение в batch сократило воемя выполнения одного из таких тестов с 17 сек до 1. Так же с ростом changelog-а будет увеличиваться время первого наката структуры.
Реализовывал схожую систему, но не для юнит тестирования, а для функционального (чтобы не соврать с терминологией — программа является черным ящиком, тесты общаются с ней исключительно через UI). Необходимо было протестировать множество отчетов на разных наборах данных.
Остановился на таком формате тестов — тестовый скрипт, содержащий набор данных, настроек и названия отчетов. При первом прогоне собирались эталонные отчеты. Эталоны проверялись руками, или не проверялись вовсе (когда количество данных было запредельным и смысл был только в отлове изменений, суть есть регрессионное тестирование). При последующих запусках эталон и текущий отчет скармливались diff-у и при наличии изменений тест помечался как имеющий различия, но не упавший. Тест падал только при невозможности выпустить отчет или ввести данные.
Для ручного тестирования, вместо того чтобы выполнять ввод исходных данных и выпуск отчета, было проще написать новый тест (не содержащий эталонных данных), запустить его, подождать пару часов (думаете отчеты быстро выпускаются? И как только раньше руками тестировал...), получить результаты, проверить и добавить новый тест в базу тестов.
Какая жалость, я рассчитывал назвать алгоритм своим именем… </:-)>
Определенно здорово, что алгоритмы над строками находят своё применение в биоинформатике и в других областях. Я не увдел статей на русском языке, описывающих этот алгоритм, потому ориентировался на приведенную вами ссылку. По ней алгоритм больше схож с исходным алгоритмом Вагнера-Фишера с инвертированными операциями. Т.е. путь будет искаться не по минимальному значению в ячейке, а по максимальному. Совпадение символов даст не 0 прирост, а максимальный 2. И "технические" первые строка и столбец заполняются не индексом строки/столбца, а нулём.
<:-)> Исходя из вышесказанного, у меня еще есть шанс попасть в историю!
Тестирование удачливости флешек.
Требуется: группа испытателей, флешки с разным дизайном, стол, под которым стоит комп с USB портами расположенными на задней стенке.
Процесс: испытатели по одному, на ощупь, пытаются вставить флешку в USB-порт компьютера, стоящего под столом.
Подсчитывается количество необходимых переворачиваний накопителя перед правильной вставкой в порт.
Процент правильного попадания с первого, второго, третьего раза — X1,X2,X3 соответственно.
X1 > 50%, lucky pass
X1 > X2 и X3, X2 > X3, usability warning
X1 > X2 и X3, X2 < X3, lucky warning
X1 < X2 или X3, lucky fail
Флешка вставлена с 4 или более раза, её удалось вставить не той стороной или сломать, при попытке вставить вывалилась из руки, испытатель выругался в процессе вставки или стукнулся головой вставая из под стола — test crash.
В примере падение происходит в строке
Mockito.when(null).thenReturn("qwerty");- в момент настройки (когда история вызовов пустая), а не в момент использования.Возможно, так проще
Общебанковские сообщества - первый движ направленный на выравнивание инженерных практик, который не вызывает отторжения. Поголовные DevOps, t-shape, платформы - все насаждалось. Ни кто не знает как правильно, ничего не работает, но НАДО, а потом переделать (намерения всегда благие, но вот исполнение и реакция...). А тут прям бальзам на душу. Хочешь - участвуй! У нас есть готовые решения, приходи и бери. Костылируй сам, ищи единомышленников, публикуй решения для остальных не в пределах своего трайба или направления, а на всех разрабов. А не хочешь - просто не делай.
В статье количество схем в пуле 10, без проблем сделать больше, просто этого хватает. В бою (не для статьи) используется не по 1 схеме на тест, а по несклько — в метаданных перечисляются схемы с разными префиксами, но одинаковыми id-суффиксами: Схема на заполнение БД и схема "пользователя без таблиц", куда только гранты на чтение выдаются.
Запускать параллельно тесты в рамках одной сборки — потратить время на создание структуры через liquibase, это накладнее по производительности. Сейчас по производительности бьет халатное отношение к ней. Если мне надо протестировать запрос на 1000 записей, у меня будет 1000 операций вставки. Объединение в batch сократило воемя выполнения одного из таких тестов с 17 сек до 1. Так же с ростом changelog-а будет увеличиваться время первого наката структуры.
Я описывал решение проблемы, когда тесты запускаются на jenkins параллельно (проверяют pull-реквесты) и каждому нужна своя база.
В статье и описано не поднятие бд на каждый тест, а выделение схемы перед запуском всех тестов с последующим освобождением.
Embedded решений я ни 1 не видел. Есть H2 поддерживающая диалект оракла, но сильно не полноценно.
Остановился на таком формате тестов — тестовый скрипт, содержащий набор данных, настроек и названия отчетов. При первом прогоне собирались эталонные отчеты. Эталоны проверялись руками, или не проверялись вовсе (когда количество данных было запредельным и смысл был только в отлове изменений, суть есть регрессионное тестирование). При последующих запусках эталон и текущий отчет скармливались diff-у и при наличии изменений тест помечался как имеющий различия, но не упавший. Тест падал только при невозможности выпустить отчет или ввести данные.
Для ручного тестирования, вместо того чтобы выполнять ввод исходных данных и выпуск отчета, было проще написать новый тест (не содержащий эталонных данных), запустить его, подождать пару часов (думаете отчеты быстро выпускаются? И как только раньше руками тестировал...), получить результаты, проверить и добавить новый тест в базу тестов.
Определенно здорово, что алгоритмы над строками находят своё применение в биоинформатике и в других областях. Я не увдел статей на русском языке, описывающих этот алгоритм, потому ориентировался на приведенную вами ссылку. По ней алгоритм больше схож с исходным алгоритмом Вагнера-Фишера с инвертированными операциями. Т.е. путь будет искаться не по минимальному значению в ячейке, а по максимальному. Совпадение символов даст не 0 прирост, а максимальный 2. И "технические" первые строка и столбец заполняются не индексом строки/столбца, а нулём.
<:-)> Исходя из вышесказанного, у меня еще есть шанс попасть в историю!
Требуется: группа испытателей, флешки с разным дизайном, стол, под которым стоит комп с USB портами расположенными на задней стенке.
Процесс: испытатели по одному, на ощупь, пытаются вставить флешку в USB-порт компьютера, стоящего под столом.
Подсчитывается количество необходимых переворачиваний накопителя перед правильной вставкой в порт.
Процент правильного попадания с первого, второго, третьего раза — X1,X2,X3 соответственно.
X1 > 50%, lucky pass
X1 > X2 и X3, X2 > X3, usability warning
X1 > X2 и X3, X2 < X3, lucky warning
X1 < X2 или X3, lucky fail
Флешка вставлена с 4 или более раза, её удалось вставить не той стороной или сломать, при попытке вставить вывалилась из руки, испытатель выругался в процессе вставки или стукнулся головой вставая из под стола — test crash.