Посоны, поясните за юнит-тесты: Как тестировать паблик метод, который принимает, например, 3 параметра, а отдает 20 (известны типы и рамки параметров)? У меня мысли такие: 1) Если есть возможность подменить источник данных (типа фейка базы или просто список объектов подставить), тогда все просто: я постоянно подкладываю одни и те же данные и сравниваю их с ожидаемым результатом, который сам нагенерил. Тогда тут вопрос - не заебусь ли я руками генерить эти ожидаемые данные? Или как это делают первый раз?2) Если нет возможности повлиять на данные, то я проверяю каждый параметр: нужного ли он типа и помещается ли он в рамки. Тогда тут вопросы: - сколько раз вызывать этот метод? Если, например, в базе есть 1 триллион записей, то сколько мне хватит проверить? 1к рандомных?- в одном тест методе будет 20 (или даже больше) ассертов?Про негативные понятно, я просто проверяю, что приходит нужная ошибка.
бумп
>>132326644
>>132326782Ну же, неужели никто не пишет юнит тесты?
>>132326929Должен быть хотя бы один сознательный программист во всем б
Не понял, что ты хочешь добиться? Смотри в свой метод, если где видишь if - надо сделать еще один тест, чтобы проверялся и случай true, и случай false.
>>132326539 (OP)1) Если уверен в нынешней реализации, и тест пишешь, просто чтобы заметить, если сломается, то используй существующую реализацию для генерации тестов. Ясен хуй, генерировать надо один раз, потом заморозить. Иначе да, руками.2) Сколько считаешь нужным. Обычно вызывают для каких-то особых наборов параметров (тут тебе виднее, скажем, 0, 0, 0), плюс два-пять-сто "рандомных". Насчет количества ассертов я никогда не парюсь. Все тесты должны проходить, похуй не пройдет один (если все ассерты в кучу) или двадцать (по одному ассерту на тест), все равно надо исправлять. По ассерту на тест может быть проще отлаживать, но обычно простота написания теста важнее.
>>132326539 (OP)Много ассертов в одном тесте это плохо.Не нужно проверять так много случаев.Параметра у тебя всего три, возьми их значения с верхней, с нижней границы и из середины. Для негативной проверки возми значения ниже нижней и выше верхней. Всего получается 3 * 5 = 15 проверок.ЗЫ какой язык и фреймворк тестирования?
>>132327553>Много ассертов в одном тесте это плохо.Чем плохо?
>>132327409Благодарю, ответ понятен. >>132327553java-junitОбщий вопрос: мне не надо проверять все пограничные значения выходных параметров?
>>132327644Один тест тестит одну вещь за раз. И должен валится в идеале только по одно по одной причине. Так проще локализовать проблему
>>132327774Не обязательно, но я бы поверил хотя бы один случай с граничным значением.
>>132327774>надоТесты пишутся не потому, что так надо, а чтобы заметить внесенную ошибку. Чем больше сложность тестируемой хуйни, тем больше желательно иметь тестов. Писать сто тестов на f(a, b) = a + b смысла нет, это просто не может поломаться ста различными способами. А вот если ты тестируешь реально сложную хрень, где каждый пограничный случай чем-то принципиально отличается от другого, то да, лучше написать тесты на все.
>>132328225>>132328220Еще раз спасибо, я всё понял, кажется.
>>132328457Я вот еще люблю тестировать "в комплексе". Юнит-тесты (по крайней мере де-юре) должны тестировать только один кирпичик. Я люблю еще набацать тестов, которые тестируют все сразу. Ну типа для компилятора задать тест: скомпилировать программу на 100 строк, да еще и проверить, что она выполняется и дает ожидаемый результат. Если такой тест сыплется, его довольно сложно отлаживать, зато набор таких тестов дает неплохую гарантия, что ошибки действительно не пройдут незамеченными.
>>132326539 (OP)Я нихуя не понял что твой метод должен делать. Если он проверяет выборку из базы то да, надо подложить ему либо базу с заданными значениями, либо вовсе mock-объект вместо настоящей базы данных.> сколько раз вызывать этот метод? Если, например, в базе есть 1 триллион записей, то сколько мне хватит проверить? 1к рандомныхНужно искать пограничные случаи, так как на них чаще всего бывают всякие баги.Например ты хочешь проверить работу выборки типа "верни мне юзеров с датой регистрации со 2 по 5 число этого месяца".Какие тут могут быть подводные камни? Очевидно что надо проверить граничные условия - что они правильно выполняются. Добавляешь в свою тестовую базу юзеров с датами 1, 2, 5, 6, проверяешь что 2 и 5 вернулось, а 1 и 6 - нет. Второй вариант (ну это на самом деле зависит уже от твоего представления данных), например если у тебя число и месяц хранятся отдельно (ну мало ли) - проверить месяц. Пишешь в базу юзера 2 числа прошлого месяца и проверяешь что он не вернется.Можно еще сделать тест в котором в базе нет ни одного юзера с нужной датой и проверить что ничего не покрашится.Ну и так далее. В принципе чем больше у тебя понимания того, как система работает, какие внутри нее проверяются условия и какие особые ситуации возможны - тем больше тестов ты можешь написать.С другой стороны тесты это всегда лишнее время, и если компонент системы некритичен то обычно пишут пару тестов, один на случайный набор данных (просто что все в целом работает), другой проверяет парочку наиболее очевидных потенциально проблемных входных наборов. Остальные тесты добавляют по мере фикса багов. Хорошее правило - каждый фикс бага сопровождается написанием теста, который во-первых показывает что баг ты действительно пофиксил и во-вторых дает проверку что он не вернется в дальнейшем (а регрессионные баги это очень злоебучая вещь).
>>132328888>Хорошее правило - каждый фикс бага сопровождается написанием теста, который во-первых показывает что баг ты действительно пофиксил и во-вторых дает проверку что он не вернется в дальнейшемНеистово двачую.
А есть тут те, кто упарывает TDD? То есть вот прямо сперва пишут тесты, а затем код под них?
>>132329193Мне лениво. Изредка бывает, но это реально только эпизодами и только если для какой-нибудь алгоритмической сложной хуйни.
>>132327409>По ассерту на тест может быть проще отлаживатьСовременные тестовые фреймворки обычно предлагают кроме ассертов (которые сразу убивают тест при фейле) еще и какой-нибудь CheckEquals. Если хотя бы один чек пофейлился то тест тоже фейлится, но при этом он доработает до конца (ну или до первого ассерта). Таким образом можно за один запуск найти все ошибочные результаты одним тестом, а не по одному за раз.
>>132329391Тоже да, но я обычно все равно ебашу ассерты. Отчасти по привычке, отчасти потому, что невыполненный чек часто делает дальнейшие проверки бесмысленными. Ну и лениво думать, что тут лучше было бы.
>>132328888Про базу хорошая аналогия, примерно то и делает тест.Меня просто смущает, что выходных параметров дохуя и у каждого куча ограничений.Я немного охуеваю, когда думаю, что в идеале для каждого случая каждого параметра надо сделать входные данные.
>>132330024>Я немного охуеваю, когда думаю, что в идеале для каждого случая каждого параметра надо сделать входные данные.А теперь подумай, насколько легко с ними налажать, раз там все сложно, и охуевать потом пытаясь отладить ошибки.
>>132330126И что делать надо?
>>132330181Превозмогать и писать тесты.
>>132330277Лады.
