В модульном тестировании так много написано, но я едва нашел какие-либо книги/блоги об интеграции тестирования? Не могли бы вы предложить мне что-то почитать на эту тему?
Какие тесты следует выполнять при тестировании интеграции? что делает хороший интеграционный тест? etc и т.д.
Спасибо
J.B. О них писал Рэйнсбергер. Здесь ссылка на статью InfoQ с дополнительной информацией.
http://www.infoq.com/news/2009/04/jbrains-integration-test-scam
Все, что написано Кент Бек, отец как JUnit, так и SUnit, - отличное место для начала (для единичных тестов/тестовой записи вообще). Я предполагаю, что вы не имеете в виду "непрерывную интеграцию", которая представляет собой процесс на основе построения (очень здорово, когда вы его работаете).
По моему опыту, интеграционные тесты очень похожи на обычные модульные тесты, просто на более высоком уровне. Более смешные объекты. Более инициализация состояния.
Я считаю, что интеграционные тесты похожи на лук. У них есть слои.
Некоторые люди предпочитают "интегрировать" все свои компоненты и тестировать "весь" продукт как тест "интеграции". Вы можете это сделать, но я предпочитаю более инкрементный подход. Если вы начинаете низкоуровневый, а затем продолжаете тестирование на более высоких слоях композиции, то вы получите интеграционное тестирование.
Возможно, сложнее всего найти информацию об интеграционном тестировании, поскольку она гораздо более специфична для реального приложения и его использования в бизнесе. Тем не менее, здесь я беру на себя это.
Что касается модульных тестов, это также относится к интеграционным тестам: модули должны иметь простой способ издеваться над внешними входами (файлы, DB, время...), чтобы их можно было протестировать вместе с другими модульными тестами.
Но то, что я нашел чрезвычайно полезным, по крайней мере для приложений, ориентированных на данные, заключается в создании "консольной" версии приложения, которая принимает входные файлы, которые полностью определяют его состояние (нет зависимости от баз данных, сети ресурсы...) и выводит результат как другой файл. Затем можно поддерживать пары файлов ввода/ожидаемых результатов и, например, проверять регрессии как часть ночных сборок. Наличие этой версии консоли позволяет упростить создание сценариев и упрощает отладку, поскольку можно полагаться на очень стабильную среду, где легко воспроизводить ошибки и запускать отладчик.