Что такое «Единица»?

Мы определяем «единицей» как отдельный класс.

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

С практической точки зрения, вероятно, всегда будут разные мнения о том, что такое «единица». Я обнаружил, что важно то, что термин используется последовательно в контексте проекта.

Могут быть разные вещи. Класс, модуль, файл ... Выберите желаемую степень детализации тестирования.

Хотя определение может быть разным, «модуль» - это отдельный фрагмент кода.

Обычно это один класс.

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

Следовательно, «единица» (также называемая «приспособлением») - это единственная проверяемая вещь - обычно это класс плюс макеты для сотрудников.

Вы можете легко протестировать пакет связанных классов, используя технологию модульного тестирования. Мы делаем это постоянно. В этих светильниках мало или совсем нет макетов.

Фактически, вы можете тестировать целые автономные прикладные программы как отдельные «блоки». Мы делаем это тоже. Предоставление фиксированного набора входов и выходов, чтобы убедиться, что все приложение работает правильно.

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

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

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

При этом я часто использую модульное тестирование при создании элементов в таких «черных ящиках» просто как средство разработки.

Я бы сказал, что модуль в модульном тестировании - это единственная ответственность для класса.

Конечно, это мнение исходит из того, как мы работаем:

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

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

Наконец, мы помогаем нашим клиентам написать приемочные тесты, которые работают с приложением в целом, чтобы увидеть, что на самом деле происходит, когда «пользователь» работает с приложением.

Это то, что заставляет меня думать, что это хорошее описание.

Если бы я работал, «единица» - это функция. Это потому, что нам не разрешено использовать в нашем дизайне что-либо, кроме функциональной декомпозиции (без ООП). Я на 100% согласен с ответом Уилла. По крайней мере, это мой ответ в рамках парадигмы моей работы в области встроенного программирования для управления двигателем, полетом и различных других систем.

По моему опыту, споры о том, «что такое единица», - пустая трата времени.

Гораздо важнее "насколько быстро проходит тест?" Быстрые тесты выполняются со скоростью 100+ в секунду. Медленные тесты выполняются достаточно медленно, чтобы вы не запускали их рефлекторно каждый раз, когда останавливаетесь, чтобы подумать.

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

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

Хотите быстрых тестов? Следуйте за Майклом Фезером правила модульного тестирования.

Но если у вас быстрые тесты и они помогают вам писать код, кого волнует, какой у них ярлык?

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

Метод - это небольшая и часто атомарная (концептуально) операция на низком уровне абстракции, поэтому ее следует тестировать.

Класс - это концепция среднего уровня, предлагающая услуги и состояния, поэтому ее следует тестировать.

Целый модуль (особенно если его компоненты скрыты) - это высокоуровневая концепция с ограниченным интерфейсом, поэтому ее следует тестировать и т. д.

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

Это не важно. Конечно, вы просите приступить к модульному тестированию - это нормально, но, повторяю, это не важно.

Это что-то вроде:

• метод, вызываемый тестом. В ООП этот метод должен быть вызван для экземпляра класса (кроме статических методов)
• функция на процедурных языках.

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

«Тест важнее единицы» (Testivus). Хороший тест должен быть:

• Автоматически - выполнение и диагностика
• Быстро - вы будете запускать их очень часто
• Атомарно - тест проверяет только одно
• Изолированные - испытания не должны зависеть друг от друга
• Повторяемость - результат должен быть детерминированным