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

Ответ 1

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

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

Помнит, Тесты идут до кода в TDD.

Ответ 2

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

Ответ 5

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

Прочитайте Блог Miško Hevery, прочитайте несколько книг (мне понравилось Test Driven от Lasse Koskela), используйте некоторые инструменты для покрытия кода, такие как Clover, а затем напишите несколько тестов.

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

Ответ 6

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

Ответ 7

Как сказал Джастин, вы должны написать свой unit test, прежде чем писать код.

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

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

Ответ 8

Ед. тесты:

• дайте уверенность в изменении рефакторинга, зная, что вы ничего не нарушаете.
• действуют как своего рода "живая документация" вашего кода, позволяя другим точно знать, как код будет вести себя в различных обстоятельствах.
• при строгом TDD, описанном @Justin, передача всех модульных тестов, написанных до начала написания кода, позволит вам знать, когда вы "закончили" кодирование. По моему опыту это также приводит к значительно упрощенному и понятному (более чистому) коду.

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

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

Ответ 9

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

Ответ 10

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

Ответ 11

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

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

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

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

Ответ 12

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