Comments 4
Не хватает конкретных примеров, чтобы можно было бы глубже понять и, так сказать, протестировать пирамиду тестирования...
На мой совершенно сторонний взгляд кажется, что тестирование должно быть неотъемлемой частью самого проектирования. Когда мы разрабатываем систему сверху-вниз, то уже как-то должны выделять реализуемые компоненты, допускающие надёжное взаимодействие. Реализация идёт обратным ходом — снизу-вверх, когда реализуется уже заранее выбранное надёжное решение.
При таком подходе к делу, система, сначала, создаётся на языке программирования, в котором реализованы средства контроля исполнения (точки наблюдения и логи), а, затем, когда необходимо выпустить релиз системы, созданная имитационная модель системы транслируется в совершенно другой язык программирования. Но и тут может потребоваться возможность перевода реальной функционирующий системы в режим тестирования для выявления неполадок.
Ну и, конечно, всё это тестирование, сколь бы крутым и комплексным оно ни было, всё-равно упрётся в нетестируемую часть — в операционную систему. И тут нас поджидает неожиданный вопрос: как должна быть устроена операционная система, чтобы обеспечить должное функционирование нашей системы?
Все зависит от сложности системы и то как на неё посмотреть.
Компонентой может быть как функция в коде, так и модуль большой монолитной программы. А интеграция может проверять как взаимодействие модулей одной системы, так и взаимодействие двух функций в рамках одного модуля. Поэтому однозначно относить unit тестирование к компонентному не всегда корректно. Также всегда почему то не упоминается про интеграционный уровень после системного, так как на этом этапе возможно тестирование интеграции нескольких систем в рамках одного e2e процесса, и ещё после приёмка в виде Альфа или Бэта тестирования.
мой вывод: эту модель можно повторять по спирали, но не стоит привязывать к конкретным методам тестирования.
«Модульных тестов всегда больше, чем тестов с других уровней.»
Почему ?
Подробнее про пирамиду тестирования