Как узнать, подходит ли ваш прибор для модульных испытаний?

Question

Как узнать, что у вас "Тестовое приспособление" правильного размера. А под «Test Fixture» я имею в виду класс с кучей тестов в нем.

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

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

Я знаю хорошую цитату для этого, и это:

"Совершенство достигается не тогда, когда нечего добавить, а когда нечего удалить". - Антуан де Сент-Экзюпери.

Answer 1

Это больше к твоему вопросу, я думаю:

Метрика, которую я использую, - «Проверяй, пока тебе не удобно» (не уверен в источнике). Я проверяю, пока не почувствую, что мой код верен. Если у вас есть сомнения, возможно, у вас недостаточно тестов. Если вы чувствуете, что напрасно тратите время, вам, вероятно, следует остановиться.

Перечитав, я думаю, что следующее не отвечает на ваш вопрос:

Исходя из этого определения Test Fixture в качестве функций настройки, объектов и фиктивных объектов, необходимых для выполнения функции тестируемой системы: когда я пишу тесты, обычно есть код, который дублируется как правило, рефакторинг этого кода и скрыть его в регионе (C #). Я стараюсь держать свои тесты в диапазоне 5-10 строк, поэтому, если есть код, который превышает это значение или скрывает смысл теста, я помещаю его в область фиксации. Я обычно не слишком беспокоюсь о размере светильника. Я больше беспокоюсь о том, чтобы убедиться, что у меня достаточно тестов и что моя функциональность проверена.

Answer 2

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

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