Год спустя, все еще борются с тестированием Unit vs Integration vs E2E

Что отличает модульные тесты и интеграционные тесты (а затем тесты подсистем и системные тесты), так это цель, которую вы хотите достичь с помощью тестов.

Цель модульного тестирования - найти те ошибки в небольших фрагментах кода, которые могут быть обнаружены, если эти фрагменты кода изолированы. Обратите внимание, что это не означает, что вы действительно должны изолировать код, но это означает, что ваш фокус является изолированным кодом. В модульном тестировании макетирование очень распространено, поскольку оно позволяет стимулировать сценарии, которые иначе трудно протестировать, или ускоряет время сборки и выполнения и т. д., Но макетирование не является обязательным: например, вы не можете имитировать вызовы математическая функция sin() из стандартной библиотеки, потому что функция sin() не мешает вам достичь ваших целей тестирования. Но оставление функции sin() не превращает эти тесты в интеграционные. Строго говоря, у вас даже могут быть модульные тесты, в которых происходит реальный доступ к сети (если вы слишком ленивы, чтобы имитировать доступ к сети), но из-за недетерминизма, задержек и т. д. Эти модульные тесты будут медленными и ненадежными, это означает, что они просто не подходят для конкретного поиска ошибок в изолированном коде. Вот почему все говорят, что «если есть реальный доступ к сети, это не юнит-тест», что не формально, а практически правильно.

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

Что же тогда такое интеграционные тесты? Они определяются целью найти ошибки во взаимодействиях между (уже протестированными) компонентами. Такие ошибки могут возникать, например, из-за взаимных неправильных представлений разработчиков компонентов о том, как должен работать интерфейс. Например, в случае библиотечного компонента B, который используется из A: вызывает ли A функции из правильного компонента B (а не из C), происходят ли вызовы, когда B уже находится в правильном состоянии (B может не работать). инициализированы или в состоянии ошибки), выполняются ли вызовы в правильном порядке, указаны ли аргументы в правильном порядке и имеют ли значения в ожидаемой форме (например, индекс с нулевым основанием или индекс с одним основанием ?, null разрешен?), возвращаемые значения представлены в ожидаемой форме (возвращенный код ошибки или исключение) и имеют значения в ожидаемой форме? Это для одного сценария интеграции - есть много других, например, компонентов, обменивающихся данными через файлы (двоичные или текстовые? Какой маркер конца строки: unix, dos, ...?, ...).

Есть много возможных ошибок взаимодействия. Чтобы найти их, в интеграционном тестировании вы интегрируете реальные компоненты (настоящий A и настоящий B, без фиктивных, но, возможно, фиктивных для других компонентов) и стимулируете их таким образом, чтобы различные взаимодействия действительно имели место - в идеале всеми интересными способами, например , пытаясь принудительно задействовать некоторые граничные случаи во взаимодействии (передаваемый файл пуст, ...). Опять же, сам факт того, что тест работает с программным обеспечением, в которое интегрированы некоторые компоненты, не делает его интеграционным тестом: только если тест специально разработан для инициирования взаимодействий, так что ошибки в этих взаимодействиях становятся очевидными, тогда это интеграционный тест. .

Затем тесты подсистем (которые являются следующим уровнем) снова сосредотачиваются на оставшихся ошибках, то есть на тех ошибках, которые ни модульное тестирование, ни интеграционное тестирование не намерены обнаруживать. Примерами являются требования к компоненту C, которые не были учтены, когда C был разложен на A и B, или, если C построен с использованием какой-то устаревшей версии A, в которой все еще сохранялась какая-то ошибка. Однако при переходе от модульного тестирования через интеграцию От тестирования до тестирования подсистем и выше, сложно оставаться сосредоточенным: только иметь тесты на ошибки, которые не могли быть обнаружены раньше, а не, скажем, повторять модульные тесты на уровне подсистемы.