Перевод статьи Джесс Анрейн «Different types of testing explained».
Однажды на стендапе наш администратор базы данных рассказывал о запуске дымовых тестов в одном из своих недавних проектов. Я и раньше слышала, как люди упоминали дымовые тесты, но почему-то никогда не тянулась почитать об этом, так что не знала по этой теме совершенно ничего. Чем такие тесты отличаются от модульных тестов? Интеграционных? Регрессионных?
На этом этапе моей карьеры было как-то даже неловко, что я не могу сказать, в чем разница между всеми этими видами тестирования. Поэтому я решила провести небольшое исследование и написать себе памятку, к которой смогу обращаться позже, чтобы не выглядеть такой уж незнайкой. Я вот проработала в должности разработчика пять лет, и у меня только сейчас встал такой вопрос. Значит, весьма вероятно, что есть и другие люди, которые не знают этой темы, но стесняются спрашивать.
Прочитав кучу различных постов в блогах, вопросов на stack overflow и других ресурсах, я составила приблизительное представление о сути нескольких различных видов тестов. Потратив еще немного времени на гугление, я обнаружила три хороших вопроса, которые помогают понять разницу между ними:
- Что именно проверяют эти тесты?
- Когда эти тесты пишутся и запускаются?
- Какую информацию дает провал тестов?
У разных людей могут быть разные определения видов тестирования, кроме того, один набор тестов может включать тесты разных видов. Например, в одном запускаемом вами наборе вполне могут быть и интеграционные, и регрессионные тесты. Это прекрасно.
Также следует учитывать, что команды имеют привычку разрабатывать свой собственный словарь, характерный только для их коллектива.
Модульные тесты (юнит-тесты, Unit tests)
Что проверяется?
Модульные тесты проверяют, правильно ли работает каждый отдельный модуль (юнит) вашего кода. В идеале при планировании и написании модульных тестов нужно изолировать функционал, который нельзя разделить на более мелкие составляющие, и протестировать его.
Модульные тесты не должны проверять внешние зависимости или взаимодействия. Вам определенно нужно сымитировать (mock out) api-вызовы. Борцы за чистоту модульных тестов будут также настаивать на имитации вызовов базы данных, чтобы убедиться, что ваш код, получая корректный input из внешних источников, ведет себя правильно.
Сможете ли вы это сделать, зависит от того, какая у вас кодовая база, и каковы предпочтения вашего менеджера. Если вы не можете исключить функционал базы данных из вашего набора юнит-тестов, помните о производительности и поищите потенциальные возможности для оптимизации.
По своему опыту могу сказать, что долго работающие юнит-тесты крайне неприятны и значительно замедляют разработку.
Когда их запускать?
Вы должны писать и запускать модульные тесты параллельно со своим кодом. Когда люди обращаются к разработке через тестирование (TDD), речь идет о модульных тестах. Эти тесты используются в качестве спецификации того, что должен делать код.
Что, если тесты провалены?
Провал модульного теста означает проблемы в определенной части кода. Если вы достаточно хорошо разбили свой код на модули (до самых маленьких), провал тестов сведется к конкретному кусочку кода, который работает не так, как нужно.
Провалы тестов должны помочь вам быстро находить и исправлять проблемы. Также они дают вам знать, когда ваши спецификации должны быть обновлены. Возможно, это еще и хороший показатель того, что нужно обновить документацию кода.
Интеграционные тесты (Integration tests)
Что проверяется?
Интеграционные тесты проверяют взаимодействие между двумя (или больше, чем двумя) отдельными юнитами вашего кода.
Ваше приложение состоит из отдельных модулей, выполняющих определенные маленькие функции. Каждый из них может хорошо работать в изолированном состоянии, но ломаться в связке с другими.
Интеграционные тесты также проверяют интеграцию вашего кода с внешними зависимостями, вроде соединений с базой данных или сторонними APIs.
Когда их запускать?
Интеграционные тесты это следующий шаг после модульных тестов.
Что, если тесты провалены?
Провал интеграционных тестов означает, что две (или больше) функции вашего приложения не работают вместе. Это могут быть два написанных вами модуля, которые приходят в противоречие из-за какой-то сложной бизнес-логики. Также провал может случиться из-за того, что изменилась структура ответа стороннего API. Провал тестов может быть предупреждением о плохой обработке ошибок в случае сбоя подключения к базе данных.
Причины провалов могут легко определяться, но могут понадобиться и мануальные проверки или определенные эксперименты. Если разобраться с провалом интеграционных тестов сложно, это может служить показателем того, что можно улучшить логи и обработку ошибок.
Регрессионное тестирование (Regression testing)
Что проверяется?
Регрессионные тесты проверяют набор сценариев, которые раньше работали и должны быть относительно стабильными.
Когда запускать?
Регрессионные тесты нужно запускать после успешного прохождения интеграционных тестов. Не добавляйте новый функционал в набор для регрессионного тестирования, пока не проведете регрессионные тесты уже имеющегося в наборе функционала.
Что, если тесты провалены?
Если регрессионные тесты провалены, это означает, что новый функционал сломал какой-то существующий функционал, приведя к регрессии.
Провал тестов дает вам знать, что сломалось что-то в старых свойствах. Это говорит о том, что нужно написать дополнительные интеграционные тесты нового и старого (сломанного) функционала.
Также провал регрессионных тестов может указывать но то, что вы случайно заново ввели баг, который уже исправляли в прошлом.
Дымовое тестирование (Smoke testing)
Что проверяется?
Дымовые тесты это высокоуровневый, тщательно отобранный набор автоматизированных тестов, занимающий место где-то между интеграционным и регрессионным тестированием. Это проверка на исправность основного функционала вашего сайта.
Термин «дымовой тест» ведет свое начало от работ, никак не связанных с программированием. Например, при пропускании дыма через трубу можно было обнаружить и устранить дефекты в ней.
Когда запускать?
Дымовые тесты должны проверять вашу систему в целом для уверенности в том, что весь основной функционал исправен. Они не должны быть всеобъемлющими. Запускать такие тесты нужно пораньше и довольно часто, в идеале – ежедневно, как в стейджинге, так и в продакшене.
Что, если тесты провалены?
Провал дымовых тестов означает заметную проблему в функционале вашего сайта. Не следует разворачивать новые изменения, пока проблемы не будут исправлены. Если подобный провал происходит в продакшене, исправление проблемы должно иметь очень высокий приоритет.
Приемочное тестирование (Acceptance testing)
Что проверяется?
Приемочное тестирование это обычно набор тестов, проводимых вручную после окончания процесса разработки. При этом проверяется, соответствует ли написанный функционал начальным спецификациям или критериям приемки.
Что, если тесты провалены?
Похоже, вы пропустили какой-то функционал при написании своего кода. Придется вернуться к разработке и исправить это. 🙁
Если приемочные тесты провалены, вам, вероятно, в следующий раз стоит пораньше определяться с критериями приемки в процессе планирования.
Когда запускать?
Поскольку это мануальное тестирование, не связанное с запуском тестов в виде кода, время проведения будет немного отличаться.
Вы с вашим project owner должны набросать критерии приемки еще до начала работ над проектом. Любые дополнительные работы, обнаруженные или добавленные к проекту, должны быть отражены и в критериях приемки.
Приемочные тесты должны проходить вскоре после завершения разработки, чтобы вы могли быстро вернуться на предыдущий этап, если что-то не соответствует критериям. Имеет смысл делать это сразу после модульного или интеграционного тестирования. Таким образом вы сможете внести необходимые серьезные изменения на раннем этапе, прежде чем продолжить процесс тестирования.
Тестирование производительности (Performance testing)
Что проверяется?
Тесты производительности проверяют стабильность, масштабируемость и возможности использования вашего продукта и инфраструктуры. Можно замерять такие вещи как количество ошибок в секунду или сколько занимает загрузка страницы. Тестирование производительности не обязательно имеет какие-то критерии прохождения или провала. Это стадия больше относится к сбору данных и поиску путей к улучшению.
Что, если тесты провалены?
Провал тестов производительности отличается от провала, скажем, модульных тестов. В их ходе вы собираете набор отметок и сверяете эти числа с желаемыми. Провал тестов производительности показывает, что нужно уделить больше внимания масштабированию инфраструктуры, времени запросов к базе данных и т. п. вещам.
Когда запускать?
Тестирование производительности будет хорошей идеей после основного релиза и рефакторинга.
Нагрузочное тестирование (Load testing)
Что проверяется?
Нагрузочное тестирование это своего рода специализированное тестирование производительности. Оно проверяет, как ваш продукт работает под значительными нагрузками в течение определенного периода времени.
Что, если тесты провалены?
Нагрузочные тесты оценивают, насколько вы готовы к существенному увеличению трафика. Если нагрузочные тесты провалены, это не значит, что ваш сайт сломан. Это значит, что вы не готовы к вирусному росту популярности вашего сайта или к DDOS-атаке. Для маленьких продуктов это может не иметь большого значения, но провал нагрузочных тестов нужно учитывать, когда ваша пользовательская база начинает расти.
Когда писать эти тесты?
Нагрузочные тесты это не то, за что следует браться как можно раньше. Но когда ваш продукт растет и прочно «встает на ноги», вероятно, стоит начать запускать нагрузочные тесты для нового функционала. Это позволит вам увидеть, как новые фичи влияют на производительность сайта в целом, а также как они могут быть оптимизированы.
Теперь я могу сказать, что знаю, что такое дымовое тестирование. Надеюсь, что и вы тоже! Поскольку я не тестировщик, то могла, конечно, что-то забыть или перепутать. Поэтому, если у вас есть что сказать касательно видов тестов, – поделитесь в комментариях!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
Мощно. Спасибо за информацию