Что для вас означает тестирование единицы измерения?

Question

G'day,

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

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

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

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

Тогда у вас есть система функциональное тестирование, тестирование ИНТЕГРАЦИЯ, приемочные испытания и т.д.

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

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

Answer 1

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

Mock classes предназначены для «имитации» интерфейса и поведения зависимых классов, чтобы метод, который я тестирую, мог вызвать их, и они будут вести себя стандартно, четко определенным образом в соответствии с системными требованиями. Чтобы этот подход работал, вызовы таких зависимых классов и их методы должны выполняться на хорошо определенном интерфейсе, так что процесс «тестера» может «вставлять» версию Mock зависимого класса в тестируемый класс от фактической производственной версии .... Это похоже на общую схему проектирования, называемую «Injection Dependency», или «Inversion of Control» (IOC)

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

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

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

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

Для получения дополнительной информации, смотрите в статье Мартина Фаулера под названием «Mocks Aren't Stubs» и статья прагматических программистов в «Mock Objects»

Answer 2

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

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

Answer 3

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

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

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

Answer 4

Wikipedia, по-видимому, предполагает, что модульное тестирование - это тестирование наименьшего количества кода, которое было бы методом класса в случае программирования OO.

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

Answer 5

Это почти повторение вопроса «What is a 'Unit'?».

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

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

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

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

Для команды, однако, их устройство может быть пакетом или полным приложением.

Answer 6

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

Answer 7

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

Answer 8

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

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

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

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

Answer 9

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

Answer 10

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

Answer 11

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

Answer 12

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

Answer 13

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