У разных людей немного разные представления о том, что представляет собой тип теста, но вот несколько идей о том, что, как мне кажется, означает каждый термин. Обратите внимание, что это сильно смещено в сторону кодирования на стороне сервера, как я обычно и делаю:)
Юнит тест
В модульном тесте должна проверяться только одна логическая единица кода - обычно один класс для всего теста и небольшое количество методов в каждом тесте. Модульные тесты (в идеале) небольшие и дешевые для запуска. Взаимодействия с зависимостями обычно изолируются с помощью двойного теста , такого как макет, подделка или заглушка.
Интеграционный тест
Интеграционный тест проверит, как разные компоненты работают вместе. Внешние сервисы (те, которые не входят в сферу действия проекта) все еще могут быть сфальсифицированы, чтобы обеспечить больший контроль, но все компоненты внутри самого проекта должны быть реальными. Интеграционный тест может проверить всю систему или некоторое подмножество.
Системный тест
Системный тест похож на интеграционный тест, но с реальными внешними сервисами. Если это автоматизировано, обычно система устанавливается в известное состояние, и затем тестовый клиент работает независимо, делая запросы (или что-то еще), как это делал бы реальный клиент, и наблюдая за эффектами. Внешние сервисы могут быть производственными или настроенными только в тестовой среде.
Зондирование
Это похоже на системный тест, но с использованием сервисов производства для всего. Они периодически запускаются для отслеживания состояния вашей системы.
Приемочные испытания
Это, вероятно, наименее определенный термин - по крайней мере, на мой взгляд; это может значительно варьироваться. Обычно это будет довольно высокий уровень, например, системный тест или интеграционный тест. Приемочные испытания могут быть определены внешним лицом (стандартная спецификация или заказчик).
Черный ящик или белый ящик?
Тесты также могут быть тестами «черного ящика», которые касаются только общедоступного API, или тестами «белого ящика», которые используют некоторые дополнительные знания для облегчения тестирования. Например, в тесте белого ящика вы можете знать, что конкретный внутренний метод используется всеми методами публичного API, но его проще тестировать. Вы можете протестировать множество угловых случаев, вызвав этот метод напрямую, а затем выполнить меньше тестов с помощью открытого API. Конечно, если вы проектируете публичный API, вам, вероятно, следует разработать его так, чтобы его можно было легко протестировать с самого начала - но это не всегда получается так. Часто приятно иметь возможность протестировать один небольшой аспект в отрыве от остальной части класса.
С другой стороны, тестирование черного ящика, как правило, менее хрупкое, чем тестирование белого ящика: по определению, если вы тестируете только то, что API гарантирует в своих контрактах, тогда реализация может измениться настолько, насколько она хочет без тестов меняется. Тесты белого ящика, с другой стороны, чувствительны к изменениям реализации: если внутренний метод изменяется незначительно - или получает, например, дополнительный параметр - тогда вам нужно будет изменить тесты, чтобы отразить это.
Все сводится к балансу, в конце концов - чем выше уровень теста, тем больше вероятность того, что это будет черный ящик. Модульные тесты, с другой стороны, вполне могут включать элемент тестирования белого ящика ... по крайней мере, по моему опыту. Есть много людей, которые вообще отказались бы использовать тестирование белого ящика, только когда-либо тестирование общедоступного API. Мне это кажется скорее догматическим, чем прагматичным, но я тоже вижу преимущества.
Начало
Теперь, что касается того, куда вам следует идти дальше, вероятно, лучше всего начать с модульного тестирования. Вы можете написать тесты до того, как разработаете свой класс (разработка через тестирование), или примерно в то же время, или даже спустя месяцы (не идеально, но есть много кода, который не имеет тестов, но должен) , Вы обнаружите, что часть вашего кода более пригодна для тестирования, чем другие ... две решающие концепции, которые делают тестирование осуществимым (IMO): внедрение зависимостей (кодирование в интерфейсы и предоставление зависимостей вашему классу, а не предоставление им возможности самим создавать эти зависимости) и test удваивает (например, фиктивные структуры, которые позволяют вам тестировать взаимодействие, или поддельные реализации, которые все делают простым способом в памяти).