Тесты, которые в 2-3 раза больше, чем тестируемый код

Нормально ли иметь тесты, которые больше, чем фактический проверенный код? Для каждой строки кода, которую я тестирую, у меня обычно есть 2-3 строки в unit test. Это в конечном итоге приводит к тому, что потраченные тонны времени просто набирают тесты (макет, макет и макет).

Где экономия времени? Вы никогда не избегаете тестов для кода, который по сути является тривиальным? Большинство моих методов имеют длину менее 10 строк, и тестирование каждого из них занимает много времени, до такой степени, что, как вы видите, я начинаю опросить большинство тестов в первую очередь.

Я не сторонник не модульного тестирования, мне это нравится. Просто хочу посмотреть, какие факторы люди рассматривают перед написанием тестов. Они приходят по стоимости (с точки зрения времени, следовательно, денег), поэтому эту стоимость нужно оценивать как-то. Как вы оцениваете экономию, создаваемую вашими модульными тестами, если когда-либо?

Ответ 1

Возможно, вы тестируете неправильную вещь - у вас не должно быть разных тестов для каждого метода в вашем коде.

У вас может быть слишком много тестов, потому что вы проверяете реализацию, а не функциональность - попробуйте проверить, как все сделано, проверьте, что сделано.

Например, если у вас есть клиент, который имеет право получить скидку на каждый заказ - создайте клиента с правильными данными и создайте заказ для этого клиента, а затем убедитесь, что конечная цена верна. Таким образом, вы фактически проверяете бизнес-логику, а не то, как это делается внутри страны.

Еще одна причина для больших тестов - отсутствие изоляции (a.k.a mocking), если вам нужно инициализировать сложные объекты, для которых требуется много кода, попробуйте использовать подделки /mocks вместо этого.

И, наконец, если у вас есть сложные тесты, это может быть запах - если вам нужно написать много кода для проверки простой функциональности, это может означать, что ваш код тесно связан, и ваши API недостаточно ясны.

Ответ 2

Unit test код должен соответствовать тому же лучшему методу, что и производственный код. Если у вас есть такой код unit test, он пахнет нарушением принципа DRY.

Рефакторинг ваших модульных тестов для использования Методы тестовой утилиты должен помочь уменьшить общий охват unit test.

Ответ 3

Слишком большой тестовый код может означать, что фактический проверенный код не был предназначен для проверки. Там отличное руководство по тестируемости от разработчиков Google, которое пытается решить эту проблему.

Плохо разработанный код означает тонны тестового кода, который имеет только одну причину: сделать реальный код тестируемым. С хорошим дизайном тесты могут быть сосредоточены больше на том, что важно.

Ответ 4

Ну,

Это компромиссный сценарий, в котором больше тестов обеспечивает стабильность. Благодаря стабильности это не только означает, что тестируемый код более беспроблемный и надежный, он дает уверенность в том, что программа не сломается в любом случае в будущем. Однако, сумасшедший, вы передаете аргументы методу, блок кода вернется должным образом (конечно, с соответствующими сообщениями об ошибках, которые необходимы).

Более того, вы можете написать свои случаи unit test, прежде чем вам придется знать внутреннюю работу тестируемого вами метода. Это похоже на сценарий "черного ящика", в котором вы сначала закончите писать свои тестовые примеры, а затем начнете кодирование. Тяжелое преимущество заключается в том, что усилия по разработке станут свободными от ошибок при меньшем количестве итераций, параллельно выполняя тестовые примеры.

И размер тестового кода не имеет значения. Все, что имеет значение, - это полнота и охват ваших модульных тестов. Является ли это просто тестом для тезки или серьезным тестовым примером, который обрабатывает все возможные случаи.

Ответ 5

Тестирование должно заключаться в поиске правильного баланса, который зависит от многих разных факторов, таких как:

Бизнес-цель (подумайте "контроллер кардиостимулятора" и "менеджер инвентаризации фильмов" )
Навыки развития персонала.
Оборот персонала (как часто люди добавляются в пул разработчиков)
Сложность (программного обеспечения, связанного с "бизнес-целью" выше)

Обычно я пишу только тесты для "общедоступного API" и тем самым неявно проверяю любые классы сборки, используемые для предоставления публичных функций. Но по мере увеличения вашего стремления к повышению надежности и воспроизводимости вы также должны добавить дополнительные тесты.

Ответ 6

Очень правильный и хороший вопрос. Я следую простому принципу, когда это необходимо.

Задайте категорию проблем, которые мы знаем (критические, высокие, низкие)
Посмотрите, сколько времени у нас есть и перегруппируйте, а затем внутренним обсуждением
установить приоритеты
Затем исправить проблемы

Хотя все это занимает немало времени, но пока мы помним, что вывод должен быть хорошим, а ошибка свободна, и мы придерживаемся выше всего, все идет хорошо.

Ответ 7

Это правда чаще, чем нет. Ключ к выяснению, хорошо ли это или плохо, выяснить причину, по которой тесты больше.

Иногда они больше просто потому, что есть много тестовых примеров для покрытия, или спецификация сложна, но код для реализации спецификации не так уж и длинный.

Также рассмотрим время, необходимое для устранения ошибок. Если тесты модулей предотвратили некоторые ошибки, те, на которые потребовалось бы гораздо больше времени для отладки и исправления, могли бы вы утверждать, что TDD сделала вашу разработку более длинной?

Ответ 8

Если вы тестируете простые (CRUD) операции, вполне логично иметь более длительные тесты
В противном случае, я полагаю, вы можете реорганизовать свой код, чтобы повторный код был перемещен в отдельные методы.
Если вы используете Java, вы можете использовать checkstyle (или другие инструменты) для проверки дублирования кода.

Ответ 9

Ну да, вполне возможно, что тесты имеют больше loc, чем фактический код, который вы тестируете, но это стоит того, чтобы учитывать время, которое вы сохраняете при отладке кода.

Вместо того, чтобы проверять все приложение/библиотеку вручную каждый раз, когда вы вносите изменения, вы можете положиться на свой testuite, и если это не удается, у вас есть более точная информация о том, где он сломался, чем "он не работает".

Об избегании тестов: если вы не тестируете определенные части вашего кода, вы фактически подрываете всю концепцию и цель тестов, а затем тесты на самом деле бесполезны.

Однако вы не тестируете материалы, которые не писали. То есть вы предполагаете, что внешние библиотеки работают правильно, а также методы getter/setter (если ваш язык поддерживает их) также не нужно тестировать. Очень безопасно предположить, что он не сбой при присвоении значения переменной.

Ответ 10

Одна из вещей, которая помогает мне, когда я пишу тесты или делаю TDD (что, кстати, я узнал из ответа на один из моих вопросов о SO), заключается в том, что вам не нужно быть столь же осторожным в отношении дизайна/архитектуры вашего тесты, так как вы должны быть о своем фактическом коде. Тесты могут быть немного грязными и субоптимальными (дизайн кода мудрым), пока они выполняют свою работу правильно. Как и все советы по дизайну, его следует применять разумно и нет никакой замены для опыта.

Ответ 11

Да, это нормально. Это не проблема, что ваш тестовый код длиннее вашего производственного кода.

Возможно, ваш тестовый код может быть короче, чем он есть, и, возможно, нет, но в любом случае вы не хотите, чтобы тестовый код был "умным", и я бы сказал, что после первого написания вы не знаете, я хочу, чтобы рефакторинг тестового кода был общим, вплоть до абсолютно необходимого. Например, если у вас есть регрессионный тест для прошлой ошибки, то, если вы не измените открытый интерфейс в тестировании, не трогайте этот тестовый код. Когда-либо. Если вы это сделаете, вам нужно будет вытащить какую-то древнюю версию реализации, начиная с момента исправления ошибки, чтобы доказать, что новый тест регрессии все еще выполняет свою работу. Пустая трата времени. Если единственный раз, когда вы когда-либо изменяли свой код, чтобы сделать его "проще в обслуживании", вы просто создаете занятую работу.

Обычно лучше добавлять новые тесты, чем заменять старые тесты новыми, даже если вы закончите с дублированными тестами. Вы рискуете своей ошибкой, но ничего не выиграете. Исключением является то, что если ваши тесты слишком долго выполняются, тогда вы хотите избежать дублирования, но даже это может быть лучше всего сделано путем разделения ваших тестов на "основные тесты" и "полные тесты" и запускайте все старые, возможно, дубликаты реже.

Также см. тестовый код SQLite на коэффициент производственного кода

Ответ 12

В моей практике TDD я склонен видеть более крупные тесты (в LOC), тестирующие классы, которые ближе к точкам интеграции системы, то есть к классам доступа к базам данных, классам веб-сервисов и классам проверки подлинности.

Интересным моментом в этих модульных тестах является то, что даже после того, как я их напишу, мне все еще неловко известно, работают ли эти классы, что заставляет меня писать интеграционные тесты с использованием службы базы данных, веб-службы или проверки подлинности. Только после того, как были установлены автоматические интеграционные тесты, я чувствую себя комфортно, двигаясь дальше.

Тесты интеграции обычно намного короче, чем их соответствующие модульные тесты, и делают больше для меня и других разработчиков в команде, чтобы доказать, что эта часть системы работает.

-HOWEVER -

Автоматизированные интеграционные тесты имеют свои собственные гадости, которые включают обработку большей продолжительности тестов, настройку и отключение внешних ресурсов и предоставление тестовых данных.

В конце дня я всегда чувствовал себя хорошо в том, что касается автоматизированных тестов интеграции, но почти всегда считал, что модульные тесты для этих "интеграционных" классов были для многих работ невыносимыми.

Ответ 13

Тесты, которые в 2-3 раза больше, не являются нормальными.

Использовать вспомогательные классы/методы в тестах.

Ограничить объем тестов.

Эффективно использовать тестовое приспособление.

Эффективно использовать тестовый разрыв.

Эффективно используйте рамки unit test.

И у вас больше не будет таких тестов.