Тестирование — достаточно надёжный способ найти ошибки ещё на этапе разработки и сохранить качество работы в процессе эксплуатации ПО. А в этой статье Антон Зеленский, Lead Software Engineer в EPAM, расскажет, какие инструменты и подходы для frontend-тестирования использовать веб-разработчику и тестировщику.
Мне кажется, сообщество разработчиков находится где-то в фазе понимания, что «бетонированию» тестами поддаются только конструкции, обещающие жить долго без изменений. В то же время мы видим повсеместное применение Agile подходов к разработке, намекающих нам на то, что подвижность, гибкость продукта во всех смыслах является одним из ключевых факторов его выживаемости на рынке.
TDD (test-driven development или разработка через тестирование) звучит бодро, когда вы делаете лабораторную работу, и совсем не так, когда вы оказываетесь на рынке и проигрываете тендер только потому, что заложили в цену тесты, актуальность которых едва ли доживёт до релиза. Очевидное противоречие между абстрактным идеальным кодом и бизнесом, который хочет дёшево, надёжно и вчера, решается в таком компромиссе: дешёвых тестов можно много, дорогих — мало. Чем больший объём функциональности покрыт тестом, тем обычно дороже стоит такой тест.
Именно так мы выходим на классику пирамиды тестов: Jest, Mocha, Jasmine и другие в юнит и интеграционных тестах; Karma, Protractor, Phantom и пр. для тестов UI компонент (которые с лёгкой подачи команды Angular стали называть E2E тестами, хотя это не всегда так). Pact как тестирование исполнения контракта между провайдером и потребителем.
Стоит отдельно упомянуть тестирование на безопасность (на моём нынешнем проекте используется Fortify), тестирование производительности (Lighthouse), тестирование на CSS регрессию (Hermione).
Узнать мнение других экспертов можно на сайте "Типичный программист".
