Как часто мы должны писать модульные тесты?

Question

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

Мой наставник / руководитель разработки просит меня написать новый пример модульного теста для вновь написанного потока управления в методе, который уже тестируется существующим классом тестирования, и я думаю, что это излишнее. Как часто вы пишете свои юнит-тесты и насколько детальными должны быть ваши юнит-тесты? Спасибо!

Answer 1

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

Требования пользователя -> Дизайн функций -> Модульные тесты -> Код

Помнит, Тесты идут раньше, чем Код в TDD .

Answer 2

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

Если вы думаете, что это излишне, спросите себя: «Если я не проверю этот код, как я узнаю, что он работает?»

Answer 3

Мой наставник / руководитель разработки просит меня написать новый тестовый блок для вновь написанного потока управления

Как этот поток управления стал записываться, если только он не был необходим для прохождения неудачного теста? Согласно определению TDD , производственный код не будет создан, если сначала не существует провального теста, который требует написания этого кода. Таким образом, вы, должно быть, писали код, используя какую-то методику последнего теста, а не TDD.

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

Я думаю, что ваш наставник, использующий фразу «всякий раз, когда это имеет смысл», может быть вредным, особенно для людей, плохо знакомых с TDD, потому что он не может принять правильное решение об этом до тех пор, пока у него не будет многолетний опыт работы, после один достиг Ri-уровня . Однажды, когда Кент Бек решил не написать тест , он был соответствующим образом прокомментирован Роном Джеффрисом: «Я доверяю вам и еще трем людям принимать правильные короткие игровые решения. . "

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

Answer 4

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

Answer 5

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

Чтение блога Miško Hevery , чтение некоторых книг (мне понравилось Test Driven Лассе Коскела), использование некоторых инструментов покрытия кода, таких как Clover и затем напишите несколько тестов.

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

Answer 6

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

Answer 7

Лично я использую модульные тесты, когда у меня большие данные, и я не хочу копировать / вставлять много файлов System.out.println и проверять их один на один. С юнит-тестами вы теряете 1 час на их запись и сохраняете большинство из них для тестирования. Для тривиальных вещей я лучше использую println tecnic или проверяю переменные отладки.

Answer 8

Правильный / исчерпывающий ответ на этот вопрос должен быть длинным, поскольку это ключевой вопрос для каждого процесса тестирования, но я отвечу следующими простыми (?) Правилами:

1. Если какой-либо вариант использования важен , напишите отдельный тест для него, чтобы кто-то другой (или вы в будущем) мог определить этот случай, прочитав или провалив тесты.

2. Если вам более 5 секунд интересно, является ли что-то важным достаточным для проверки или нет, тогда предположите, что это: -)

3. Если по какой-либо случайной проверке этот случай является очень сложным / дорогостоящим, пожаловайтесь об этом своему менеджеру / техническому руководителю и пропустите написание теста.

Answer 9

Вы всегда должны писать тест, если ваш существующий набор тестов недостаточен. Лучший признак того, что ваших тестов недостаточно, - это ошибки. Поэтому хорошей практикой является написание юнит-теста для каждой ошибки, с которой вы сталкиваетесь. С разработкой, управляемой тестами, вы должны начать с некоторого теста, определив функциональность класса. Утилиты test-cover-tools дают несколько советов, какие части могут потребовать дополнительного тестирования.

Answer 10

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