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