Как вы говорите, лучший подход зависит от приложения. Однако, как правило, рекомендуется иметь набор интеграционных тестов, которые могут протестировать ваше приложение от начала до конца, чтобы выявить любые проблемы, которые могут возникнуть при обновлении только одного уровня приложения без учета этих изменений. в другом слое. Похоже, что в вашем случае это было бы определенно полезно, учитывая, что у вас есть системные компоненты, написанные на разных языках, что, естественно, увеличивает вероятность возникновения проблем из-за дополнительной сложности интерфейсов компонентов.
Одна вещь, о которой следует помнить при написании сквозных интеграционных тестов (которые некоторые называют системными тестами), заключается в том, что они, как правило, довольно хрупкие по сравнению с модульными тестами, которые представляют собой комбинацию ряда факторов, в том числе:
- Они требуют наличия нескольких компонентов для тестов и правильной настройки связи между этими компонентами.
- Они выполняют больше кода, чем модульный тест, и поэтому есть больше вещей, которые могут пойти не так, что может привести к их сбою.
- Они часто включают асинхронную связь, для которой написать тесты сложнее, чем для синхронной связи.
- Они часто требуют сложной настройки серверных данных, прежде чем вы сможете провести тесты через все приложение.
Из-за этой хрупкости я бы посоветовал попытаться написать как можно меньше тестов, которые проходят через весь стек. Основное внимание должно быть сосредоточено на охвате как можно большего количества функций в наименьшем количестве возможных тестов с предвзятостью. к вашим наиболее важным функциональным вариантам использования. Хорошей стратегией для начала будет:
- Выберите один ключевой вариант использования (который в идеале затрагивает как можно больше компонентов приложения) и поработайте над созданием сквозного теста для него (даже сам по себе этот единственный тест принесет большую пользу). Сосредоточьтесь на том, чтобы сделать этот тест максимально реалистичным (т. е. использовать развертывание, подобное производственному), максимально надежным и максимально автоматизированным (в идеале он должен выполняться как часть непрерывной интеграции). Даже просто наличие этого единственного теста имеет большую ценность.
- Создавайте тесты для других вариантов использования по одному тесту за раз, снова сосредоточившись сначала на наиболее важных вариантах использования.
Такой подход поможет обеспечить высокое качество ваших сквозных тестов, что жизненно важно для их долговременной работоспособности и полезности. Слишком много раз я видел, как люди пытались внедрить в приложение полный набор таких тестов, но в конечном итоге терпели неудачу, потому что тесты хрупкие и ненадежные, люди теряют в них веру, не запускают и не поддерживают их и, в конце концов, забывают, что они даже были тесты в первую очередь.
Удачи и приятного времяпровождения!
person
robjohncox
schedule
04.07.2013
