Что такое «Единица»? [закрыто]

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

В то время как определение может варьироваться, "единица" является автономной частью кода.

Обычно, это - единый класс.

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

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

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

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

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

Мы определяем 'единицу', чтобы быть единым классом.

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

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

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

Однако я часто использую поблочное тестирование при создании объектов в таких 'черных квадратах' как помощь в целях развития.

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

, Конечно, это мнение прибывает из способа, которым мы работаем:

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

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

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

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

По моему опыту, дебаты о, "что является единицей", являются пустой тратой времени.

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

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

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

Хотите быстрые тесты? Следуйте за Michael Feather правила поблочного тестирования .

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

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

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

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

, класс А является понятием среднего уровня, которое предлагает услуги и состояния и должно поэтому быть протестировано.

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

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

Это не важно . Конечно, нормально, что Вы просите начинать на поблочном тестировании, но я повторяю его, это не важно.

единица - что-то вроде:

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

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

"Тест более важен, чем единица" ( testivus). Хороший тест должен быть:

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