Продолжить обсуждение из Можно ли обойтись без page object паттерна:
Именно потому, что “Пирамида” набила всем оскомину, самое время ее обсудить.
Я понимаю, что сам принцип пирамиды не лишен здравого смысла. Лично на моих глазах, картинка найденной пирамиды в гугле – становилась весомым аргументом в обсуждении и отстаивании не совсем здравых идей, мол:
- Вот есть пирамида.
(Все: кивают головой)
- Это практически стандарт в тестировании
(Все: кивают головой)
- Вот перевернутая пирамида. Люди говорят что это плохо.
(Все: кивают головой)
- Значит давайте (*безумная идея тут*)
И тут я подумал, а может быть пирамида так притягательна не из-за глубокой идеи, а из за геометрической формы?
В этой теме я приглашаю придумать и обсудить геометрические идеи в автоматизации тестирования.
Но, для справки приведу пирамиду (треугольник) автоматизации
Ссылки:
Пирамида правильная:
Идея: пишите больше юнит тестов, потому что они “дешевые”, быстрые и должны быть фундаментом.
Потом интеграционные, ну а UI и мануального тестирования должно быть совсем мало.
Пирамида перевернутая:
Идея: ну вот, начали с UI автоматизации и теперь не можете остановится. Напишите хоть немного юнит тестов.
Часто используется в негативном контексте с примером длительного ожидания завершения прогона UI тестов.
Квадрат автоматизации
Вот пошло мое творчество Хотя может эта идея у кого еще есть.
Идея в том, что все виды тестирования должны иметь равные права и быть независимыми.
Добавляйте тесты по требованию и в зависимости от контекста. Т.е. если вы считаете что вам необходим юнит-тест в каком-то труднодоступном месте – напишите его. А если вы считаете, что некий функционал уже перекрыт UI тестом – то оставьте как есть. Но, не должно быть пропорции: 1 UI тест = 3 интеграционных = 9 юнит тестов.
UI тесты отлично подходят для happy path сценариев. Интеграционные и юнит тесты для редких случаев, которые действительно сложно (и медленно) покрыть UI тестами.
Инь Янь автоматизации
Идея в том, то уделять мануальному тестированию вы должны столько же времени, сколько и автоматизации.
Мануальное тестирование – это не не бездумное кликанье по excel спредшиту – это лучше отдать на автоматизацию. Мануальное тестирование – это просто тестирование – исследовательское тестирование: придумывание новых экспериментов над приложением, добыча новой информации, уточнение требований, создание новых юскейсов. Нередко можно увидеть автоматизатора и даже разработчика, который не понимает общей идеи продукта и не видит дальше своего кода.
Пирамида тестирования – вид сверху
Говорит, что UI тесты – самые важные (центральные). Просто потому что в итоге, нашем приложением будут пользоваться люди, в большинстве случаев через UI.
Конечно, есть случаи когда в продукте нет UI, например если продукт – это API сервис либо библиотека.
Тогда центральными становятся интеграционные и API-тесты.
Юнит тесты имеют самый низкие приоритет и служат лишь в помощь.
Я напомню, что юнит-тест – это тест конкретного класса или метода или функции.
Если вы используете несколько классов в одном тесте и сроете целые тестовые сценарии – то это уже интеграционный тест по определению.
Эта пирамида не означает то, что у вас должно быть больше всего юнит-тестов. Откуда вы знаете, может она внутри пустая, а все что вы видите сверху – это тонкие стенки?
Единственное о чем я не спорю – это о важности наличия и юнит и интеграционных и UI и “исследовательско-мануальных тестов”, но не стоит загонять их в рамки геометрической фигуры.
Или стоит? Если да – то предложите свой вариант.