Разделение юнит-тестов

Question

Этот вопрос относится к PHPUnit, хотя должен быть глобальным вопросом проектирования xUnit.

Я пишу тестовый блок для класса Image.

Один из методов этого класса - setBackgroundColor().

Для этого метода нужно протестировать 4 различных поведения,

1. Попытка установить недопустимый цвет фона. Будет проверено несколько недопустимых параметров.
2. Попытка установить допустимый цвет фона с использованием сокращенного массива RGB, например, array(255,255,255)
3. Попытка установить допустимый цвет фона, используя стандартный массив RGB, например, array('red' => 255, 'green' => 255, 'blue' => 255) (это выходной формат функции GD imagecolorsforindex())
4. Попытка установить допустимый цвет фона с помощью прозрачной константы IMG_COLOR_TRANSPARENT

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

Мой вопрос: что мне здесь делать? Должен ли я инкапсулировать все это в 1 тест из тестового примера Image, или я делю вышеупомянутое на отдельные тесты, такие как,

• testSetBackgroundColorErrors
• testSetBackgroundColorShorthandRGB
• testSetBackgroundColorRGB
• testSetBackgroundColorTransparent

Я поставил тест здесь http://pastebin.com/f561fc1ab.

Спасибо

Answer 1

Разделите это. Совершенно верно.

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

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

Answer 2

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

• Это делает более очевидным, что пошло не так, когда тест не пройден и, следовательно, быстрее отлаживается
• Вы получаете преимущество сброса объектов в чистое начальное состояние между условиями испытаний
• Теперь легче увидеть, какие тесты вы включили / пропустили, просто взглянув на имена методов

Answer 3

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

Answer 4

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

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

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