Так почему же пирамида?

Почему же все-таки пирамида тестирования? Не куб, не цилиндр, не шар, а именно пирамида? Постараюсь просто описать то, как я это вижу.

На сколько всем известно, тесты бывают разные. Возьмем в качестве примера функциональные и рассмотрим их на трех основных уровнях тестирования: модульном, интеграционном и системном.

Занимаясь системным тестированием, ты видишь уже готовое приложение. Берешь сторонний инструмент и пишешь тесты, оперируя внешними компонентами доступными конечным пользователям.

“Вводишь в поле слово, нажимаешь на кнопку, и не получая того, что ожидал, заводишь дефект. Пусть разработчики мучаются дальше. В особых случаях, лезешь в лог приложения, находишь конкретную запись об ошибке и прикрепляешь её в баг репорту.”

Вроде бы все хорошо, но не до конца… Именно этими мыслями я и хотел немного поделиться.

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

На лицо экономия времени и ресурсов. Минус лишь в том, что некоторая часть функционала тестируется изнутри, а не снаружи, как это видит конечный пользователь. Степень критичности этого недостатка будет зависеть от серьезности приложения и рисков возникновения проблем связанных с работой пользователей через GUI.

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