Comments 11
Швы? Это что-то новенькое? Как это называется в оригинале?
Вместо того чтобы искать, идите по URL‑адресу в карточку товара — это сэкономит много времени и снизит риски, за счёт исключения лишних шагов.
А потом этот товар будет удален из базы данных. И все ваши тесты поваляться.
Обычно работают с тестовой копией базы данных, чтобы исключить внешние изменения, поэтому не понимаю пока, зачем удалять товар, что используется в тестировании. Если вам подходит, можно еще согласовать сценарий, при котором перед началом теста отправляется POST‑запрос на создание товара, затем использовать его URL, а в постусловии удалять созданный товар, чтобы не засорять базу данных. Тогда у вас будет гарантированно свежий и рабочий URL при каждом запуске. Главное — правильная стратегия и постепенное улучшение процессов.
Не всегда есть возможность работать с базами данных. Я, как минимум, работал на пяти проектах, где такой возможности не было. Вашу статью могут прочитать новички, которые, не понимая контекста, просто скопируют URL и построят вокруг него множество автотестов, которые затем упадут.
Что касается POST- или GET-запросов, я сам так поступаю, если у меня нет доступа к базе данных. Но, опять же, если статья ориентирована на начинающих автоматизаторов, для них это будет довольно сложно реализовать.
Как упоминалось в статье, прежде чем приступать, нужно многое обдумать. Эта рекомендация полезна не только для новичков в автоматизации. Если товар находится не в тестовой базе данных или копии продакшена, я рекомендую на ретроспективе задать вопрос «почему», предложить и обсудить возможные улучшения. Тем не менее, ваш отзыв помогает сделать материал полезнее и понятнее для начинающих автоматизаторов, за что вам огромное спасибо.
Хотелось бы, конечно, почитать что-то подобное, только не про веб-приложения. А про мобилки и десктопы. А то вот эти вот все урлы карточек товаров - ну уж больно примитивное.
Эта пирамида не работает, в современной разработке, юнит тесты либо не пишутся вовсе, либо покрывают только критически важную часть кода. Вместо того, чтобы писать тысячи юнит тестов, можно написать API тесты на уровне сервиса и протестировать сразу весь компонент целиком, а не отдельные его куски. Конечно, это работает если у вас есть сервисы в проекте.
Статья для начинающих автоматизаторов, и я старалась донести мысль не начинать покрытие с UI‑тестов, а пирамида тестирования — это базовая концепция, которая помогает расставить приоритеты и найти баланс между уровнями.
Считаю, что пирамида работает. Другое дело, что юнит‑тесты часто не пишут от простого отсутствия задачи и отсутствия такой привычки у разработчиков — как, например, ставить висячую запятую в JS‑объектах, не пишут при нехватке времени, которое компания закладывает в ресурсы, но стоит отметить, что тоже часто — на основании оценки разработчика, ведь тот сам рассчитывает время при планировании реализации задачи и др. Тем не менее, вы правы, подходы к тестированию зависят от контекста и специфики проекта. Если проект позволяет больше полагаться на API‑тесты, это здорово. Но, как мне кажется, полностью отказываться от юнит‑тестов не стоит — хотя бы для покрытия критически важных частей кода. Спасибо за ваш комментарий — он подчеркивает, что в тестировании как везде, успех реализации зависит от гибкости и осознанного подхода.
Основы разработки для автоматизации тестирования