Когда следует прекратить юнит-тестирование?

Question

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

В какой момент вы останавливаетесь и решаете, что преимущества модульного тестирования не стоят затрат?

Answer 1

Когда вы можете обеспечить большую ценность, делая что-то еще.

Answer 2

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

Answer 3

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

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

Answer 4

Если вам нужно прекратить тестирование, исключите интеграцию или сквозное тестирование. Миско Хевери в Google объясняет это очень хорошо здесь .

"Модульное тестирование дает вам больше возможностей для ваш доллар "

- лучшая цитата из его статьи.

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

Answer 5

Если вы используете TDD, то вы прекращаете модульное тестирование, когда все тесты в списке тестов завершены успешно.

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

Answer 6

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

Если вы посмотрите на тестовые проекты в выпуске Visual Studio Team для тестировщиков, есть такой элемент, называемый «Ручной тест», который по сути является документом с инструкциями, чтобы рассказать человеку, как выполнить тест и вручную его пройти. , Некоторые вещи, такие как тестирование пользовательского интерфейса или код для обхода непонятного или странного поведения оборудования в базовой платформе, ОС или драйвере, лучше проверяются человеческими глазами.

Answer 7

Что касается тестирования доступа к данным, вы пробовали пробные тесты для имитации ответов.

Answer 8

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

Answer 9

Мне нравится название вопроса. Кроме того, я думаю, что это обман Есть ли такая вещь, как чрезмерное юнит-тестирование?

Answer 10

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