Функциональные тесты очень важны. Да, им нужно время, чтобы написать, но если вы пишете правильные функциональные тесты, они того стоят.
Есть несколько веских причин для проведения автоматических функциональных тестов в приложении.
- Когда новая функция добавляется на ваш веб-сайт, она сразу дает вам знать, нарушают ли изменения, сделанные для этой новой функции, какие-либо другие функции на вашем сайте.
- Это документированное знание того, как приложение работает и работает вместе для достижения бизнес-требований.
- Когда пришло время обновить стороннюю библиотеку, вы можете обновить ее и запустить свой функциональный набор тестов, чтобы увидеть, что-то не работает. Вместо того, чтобы просматривать каждую страницу самостоятельно, вы можете попросить компьютер сделать это за вас и предоставить список всех пройденных тестов.
- Нагрузочное тестирование! Вы можете смоделировать тысячи одновременных пользователей, одновременно попадающих на ваш сайт, и вы можете увидеть, где ваш сайт замедляется и сжимается под давлением. Вы можете увидеть, как ваш веб-сайт ведет себя задолго до того, как вы получили поздний ночной звонок о том, что сайт рухнул.
- Функциональное тестирование требует времени, чтобы сделать вручную. Да, для написания кейсов требуется много времени, но если вам пришлось сесть с переплетом с 500 страницами тестов, которые вам пришлось пройти, прежде чем вы смогли отгрузить продукт, вы бы хотели, чтобы у вас были автоматизированные тесты!
- Документы тестирования быстро устаревают. Когда добавляется новая функция, вы должны обязательно обновить основной документ тестирования. Если кто-то пропускает некоторые тесты, вы внезапно получаете ошибки, попадающие на страницы, которые «сделаны и протестированы». В настоящее время я работаю в такой среде, и могу вас заверить, это кошмар.
В конце концов, да, для написания этих дел требуется время, но вы должны гордиться их написанием. Это ваш способ доказательства, без тени сомнения, что ваш код работает и работает со всеми остальными функциями. Когда QA приходит к вам и говорит, что есть ошибка, вы исправляете ее, а затем добавляете в свой набор тестов, чтобы показать, что она исправлена, и убедиться, что она больше никогда не повторится.
Это ваша сеть безопасности. Когда кто-то заходит и захватывает сохраненный процесс и вносит небольшие изменения, чтобы он работал со своим кодом, вы поймете, что он нарушил 3 других функции в процессе. Вы поймете это в ту ночь, а не в ночь перед крайним сроком!
Что касается написания функциональных тестов только для критических функций системы. Это не даст вам полную картину, и это позволит ошибкам проникать. Все, что нужно, это добавить одну маленькую функцию, которая не критична для системы, но косвенно взаимодействует с критичной для системы функцией, и у вас есть потенциальная возможность появления ошибки.