0 added
0 removed
Original
2026-01-01
Modified
2026-03-10
1
<p>Теги: тестирование, автоматизация, end-to-end</p>
1
<p>Теги: тестирование, автоматизация, end-to-end</p>
2
<p>Хотите ускорить создание новых автотестов, заодно упростив поддержку старых? Постарайтесь избавиться от громоздких<strong>end-to-end-кейсов</strong>там, где это возможно. Это станет хорошим шагом на пути к оптимизации автотестирования на проекте.</p>
2
<p>Хотите ускорить создание новых автотестов, заодно упростив поддержку старых? Постарайтесь избавиться от громоздких<strong>end-to-end-кейсов</strong>там, где это возможно. Это станет хорошим шагом на пути к оптимизации автотестирования на проекте.</p>
3
<p>Сами по себе end-to-end-тесты, разумеется, хороши. Однако бывают ситуации, когда необходимо поверить лишь один конкретный экран или даже конкретную часть информации, которая на этом экране находится. Согласитесь, довольно накладно проходить все стадии, начиная с авторизации пользователя.</p>
3
<p>Сами по себе end-to-end-тесты, разумеется, хороши. Однако бывают ситуации, когда необходимо поверить лишь один конкретный экран или даже конкретную часть информации, которая на этом экране находится. Согласитесь, довольно накладно проходить все стадии, начиная с авторизации пользователя.</p>
4
<p>Допустим, тестируемый продукт - это интернет-магазин, а нам надо проверить лишь чек, который будет отправлен покупателю после покупки конкретного товара. В случае с<strong>end-to-end-проходкой</strong>мы для получения одного-единственного экрана заходили бы по зарегистрированному паролю и логину, выбирали бы товар, потом подтверждали покупку и т. д. и т. п., то есть выполняли бы много шагов, которые, по большему счету, не связаны с конкретной задачей тестирования. При этом достаточно вспомнить, что каждый шаг занимает время, причем немалое. К примеру, проходка такого end-to-end-пути целиком может занять до 2 минут, тогда как проверка конкретного экрана - не более 10 секунд.</p>
4
<p>Допустим, тестируемый продукт - это интернет-магазин, а нам надо проверить лишь чек, который будет отправлен покупателю после покупки конкретного товара. В случае с<strong>end-to-end-проходкой</strong>мы для получения одного-единственного экрана заходили бы по зарегистрированному паролю и логину, выбирали бы товар, потом подтверждали покупку и т. д. и т. п., то есть выполняли бы много шагов, которые, по большему счету, не связаны с конкретной задачей тестирования. При этом достаточно вспомнить, что каждый шаг занимает время, причем немалое. К примеру, проходка такого end-to-end-пути целиком может занять до 2 минут, тогда как проверка конкретного экрана - не более 10 секунд.</p>
5
<p>Именно поэтому целесообразно перейти к так называемым атомарным проверкам, которые обращаются лишь к тому экрану, который интересует нас в рамках прохождения тест-кейса.</p>
5
<p>Именно поэтому целесообразно перейти к так называемым атомарным проверкам, которые обращаются лишь к тому экрану, который интересует нас в рамках прохождения тест-кейса.</p>
6
<p>Также для сравнения экранов можно внедрить<strong>snapshot-тестирование</strong>- оно позволит проверить большую часть UI. А уже имея тесты и код программного приложения в одном репозитории, вы сможете задействовать в тестах методы этого приложения. И, соответственно, находить ошибки при сравнении тестовых снимков экрана с эталонными снимками.</p>
6
<p>Также для сравнения экранов можно внедрить<strong>snapshot-тестирование</strong>- оно позволит проверить большую часть UI. А уже имея тесты и код программного приложения в одном репозитории, вы сможете задействовать в тестах методы этого приложения. И, соответственно, находить ошибки при сравнении тестовых снимков экрана с эталонными снимками.</p>
7
<p>Подход со snapshot-тестами позволяет заметно уменьшить время проверки готовой версии приложения перед отправкой на продакшн. А весь набор таких тестов может запускаться автоматически при открытии pull request’а и прогоняться в течение часа, в результате чего разработчики быстро получат фидбек о проблемах в текущей ветке.</p>
7
<p>Подход со snapshot-тестами позволяет заметно уменьшить время проверки готовой версии приложения перед отправкой на продакшн. А весь набор таких тестов может запускаться автоматически при открытии pull request’а и прогоняться в течение часа, в результате чего разработчики быстро получат фидбек о проблемах в текущей ветке.</p>
8
<p>Конечно, определенное количество end-to-end-тестов на проекте быть должно. Но они оправданы лишь там, где нужна проверка больших бизнес-сценариев. Просто помните об этом.</p>
8
<p>Конечно, определенное количество end-to-end-тестов на проекте быть должно. Но они оправданы лишь там, где нужна проверка больших бизнес-сценариев. Просто помните об этом.</p>
9
<p><em>По материалам https://habr.com/ru/company/maxilect/.</em></p>
9
<p><em>По материалам https://habr.com/ru/company/maxilect/.</em></p>
10
10