Добра піраміда - погана піраміда

Разом із усвідомленням необхідності писати автоматизовані тести, програмісти все більше загрузають у болоті тестерської термінології (вони думають, вона є узгоджена >:-E  ).

Просто пірамідки, що обертаються з TUTORIAL 1 - OpenGL Fundamentals http://www.naturewizard.at/tutorial0104.html

 Усі тестери, що починали саме як тестери, намагаючись щось автоматизувати, інтуїтивно хочуть у своїх "авто-тестах" повторювати ті самі кроки, що робили руками до того. Але у певний момент зіштовхуються з проблемою підтримки UI-них авто-тестів. І після болісних ударів долі їм нарешті являється "священна піраміда автотестування", яка їм наказує:

• піклуйся про дослідницьке тестування, орієнтоване на користувача;
• пиши менше UI-них тестів, бо задовбаєшся їх переписувати весь час;
• вчися тестити бек-енд без використання UI;
• програмісти мають тестити свій код, а оскільки вони програмісти - тестити його вони повинні юніт-тестами, що також являються кодом. І цих юніт-тестів має бути багато! Набагато більше, ніж твоїх UI-авто-тестів. 
• І звідси найголовніший висновок: Не парся тестувати дуже глибоко, хай в глибині програмісти самі все тестують своїми триліардами юніт-тестів!

Це те, що бачать тестувальники. І це має користь і сенс для них. 

 Справжня піраміда авто-тестування 

звідси http://james-willett.com/2016/09/the-evolution-of-the-testing-pyramid/

З іншого боку, коли програмістам показують "піраміду", намагаючись обґрунтувати, чому вони МУСЯТЬ писати триліарди юніт-тестів, це викликає обурення їхнього логічно узгодженого всесвіту.
Ось і шановний Браян Оккен (Brian Okken @brianokken), що працює програмістом без тестерів і сам відповідає за якість свого коду, в останньому своєму подкасті (https://testandcode.com/31) стикнувся із труднощами розуміння такого підходу.
Спробую навести кілька його та моїх власних критичних думок, чому "піраміда" - погана модель:

1. Що є той "юніт", який має тестуватись "юніт-тестами"? Яка грануляція на юніти є достатньою? Чому не глибше? Або чому не загальніше? 
2. Те саме з "інтеграційними тестами". Чи кожен шар абстракції має бути покритий? Чи достатньо найвищого? Чи найнижчого?
3. Дивлячись на цю модель, легко подумати, що все тримається на юніт-тестах, і якщо їх нема - гаплик всьому. Але практика показує, що це далеко не так. Існує дуже багато продуктів і цілих еко-систем (я бачив багато успішних проектів на PHP), де не писати юніт-тести - нормально. Хтось може зауважити, що там нижча якість коду. Але чи скрізь потрібен "вищий ґатунок"? Якщо переважна більшість користувачів задоволені якістю продукту (не забувайте, що у поняття "якість" включено і ціну розробки), то можливо, здорожчувати розробку не має сенсу?
4. Чи не є "кількість тестів" помилковою метрикою? Якість тест-дизайну дуже залежить від контексту. 10 поганих юніт-тестів можуть досягти 100% покриття коду (виразів, умов, рішень). Але вони будуть не валідними з точки зору семантики використання даного модулю. "Святі отці" програмування давно відмовились від вимірювання коду "кількістю рядків". "Святі отці" тестування майже переконали всіх, що кількість виконаних ручних тестів теж ні про що не говорить з точки зору функціонального покриття. То чому найпоширеніша модель автоматизованого контролю якості ґрунтується на банальній "кількості тестів"? Це точно примітивно, і здається, не дуже надійно. Що доводить практика. 
5. Уявімо, що є 1 широко параметрізований автоматизований тест, що запускається із великою кількістю різних даних. Чи цікавить нас, що він один? Ні. Чи цікавить нас кількість наборів даних? Не думаю, що сильно. Адже нас насправді цікавить варіативність цих даних, які функціональні області вони зачіпають, і як відносяться до реальних даних з продакшена. І цього не можна намалювати на піраміді у її теперішньому вигляді.

Висновку ще нема. Бо власної моделі я ще не сформулював. Відкритий до дискусії з цього приводу!