Что для вас значит юнит-тестирование?

Question

G'day,

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

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

Это не соответствует моей интерпретации того, что такое юнит-тестирование.

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

Затем у вас есть функциональное тестирование системы, интеграционное тестирование, приемочное тестирование и т. Д.

Я хочу знать, это немного педантично с моей стороны? Или это то, о чем вы думаете, когда ссылаетесь на юнит-тесты и юнит-тестирование?

Редактировать: Роб Уэллс. Мне необходимо уточнить, что подход к такому тестированию с точки зрения черного ящика - это только один аспект. При использовании фиктивных объектов для проверки внутреннего поведения вы действительно тестируете с точки зрения белого ящика, потому что знаете, что хотите, чтобы происходило внутри ящика.

Answer 1

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

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

Answer 2

Я пытаюсь реализовать модульные тесты, чтобы протестировать только один метод. и я прилагаю усилия, чтобы создать "фиктивные" классы для зависимых классов и методов, используемых методом, который я тестирую ... ... так что выполнение кода в этом методе на самом деле не вызывает код в других методах, модульный тест не должен быть «тестированием» (существуют другие модульные тесты для этих методов). Таким образом, сбой модульный тест достоверно указывает на сбой метода, который тестирует модульный тест ...

Ложные классы предназначены для «имитации» интерфейса и поведения зависимых классов, чтобы тестируемый мной метод мог вызывать их, и они будут вести себя стандартным, четко определенным образом в соответствии с системными требованиями. Для того чтобы этот подход работал, вызовы таких зависимых классов и их методов должны выполняться в четко определенном интерфейсе, чтобы процесс «тестера» мог «внедрить» версию Mock зависимого класса в проверяемый класс. фактической версии производства .... Это похоже на общий шаблон проектирования, называемый «Внедрение зависимостей» или «Инверсия управления» (IOC)

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

Редактировать: Роб Уэллс. @Charles. Спасибо за это. Я забыл использовать фиктивные объекты для полной замены другими классами, кроме тестируемого.

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

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

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

Answer 3

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

Answer 4

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

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

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

Поймите, это не ответ на все вопросы качества, это просто полезный инструмент, который вы используете.

Answer 5

Я слышал о методах, в которых многие из модульных тестов выполняются первыми, а разработка ведется вокруг них. Кто-то только что прокомментировал, сказав, что это «разработка через тестирование» - TDD (Спасибо, Эли).

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

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

Answer 6

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

Answer 7

существует традиционное представление http://en.wikipedia.org/wiki/Software_testing как части http://en.wikipedia.org/wiki/Software_engineering., но мне нравится идея гибкого модульного теста: тест - это гибкий модульный тест, если он достаточно быстр, чтобы программисты всегда запускают его.

Answer 8

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

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

Answer 9

Это почти повторение вопроса " Что такое" Единица "? ".

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

Возможно, они думают о модуле как о большой сборке кода. Который не самое желательное определение.

Хотя я согласен, что у вас есть несколько уровней тестирования (модуль, модуль, пакет, приложение), я также думаю, что многое из этого можно сделать с помощью инструментов модульного тестирования. Ведущий к «что такое единица?» вопросы возникают все время.

Единица зависит от контекста. Для индивидуального разработчика единица должна быть Классом. Иногда это также означает модуль или пакет.

Однако для команды их подразделение может быть пакетом или полным приложением.

Answer 10

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