Это нормально, если мои модульные тесты содержат 1-2 метода на класс?

Question

Когда я тестирую свою простую геометрическую библиотеку, у меня обычно есть один или два метода в каждом тестовом классе. Все, что я проверяю, это то, что объекты правильно вычисляют координаты или нет. Это нормально (имеется в виду количество методов)?

Answer 1

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

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

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

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

Хорошей практической книгой, которую я прочитал о модульном тестировании, является Прагматическое модульное тестирование в C # с nUnit . Он предоставляет удобное руководство по многим вопросам, таким как этот.

Answer 2

С этим нет врожденной проблемы, и при этом это не указывает на тестовый запах сам по себе.

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

• Тестовый класс на класс
• Класс теста для каждой функции
• Класс теста для каждого прибора

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

Answer 3

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

Answer 4

My 2c / 2p:

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

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