если тестируете "нажатие кнопки" то создайте компонентный юнит тест для именно этой кнопки

 

А как мне написать тест на "нажатие кнопки" если например, чтобы нажать эту кнопку, нужно до нее дойти, и перед этим сделать еще кучу действий. У меня есть конкретный пример на проекте. Мне нужно загрузить задание в спецификацию. Но чтобы дойти до загрузки этого задания, мне нужно полюбому пройти еще 3 страницы со своей логикой работы. Сразу перейти на страницу загрузки задания - невозможно, потому что стоит валидатор на необходисость заполнить нужные поля на всех предыдущих страницах...

Отложите автоматизацию на пару месяцев и приведите в порядок ваши тесты. 30 - 50 шагов на тест это нечто за гранью. Если вы сейчас это автоматизируете, то через полгода проклянете свою работу из-за постоянной поддержки кода.

Как мне кажется, это все равно не решит проблему. Нужно как-то менять саму архитектуру автотестов. А с этим как раз проблемы.

2. UI тесты заменяются API- тестами, но не все, основные сценарии все равно надо проходить через UI

 

 На этот счет у меня есть идея. Приведу пример. Если я правильно вас понял, то например в моем web приложении, в UI есть кнопка, при нажатии на которую  дергается какая-то API ручка. Если я напишу тест на этот API я покрою проверку работы кнопки?  Ну и соответсвтенно если при нажатии на другую кнопку API ручка не дергается, то следовательно на эту кнопку нужно писать полноценный UI тест?

Доброго времени суток. Надеюсь что сможете подсказать и навести на путь истинный вы выборе подхода к автоматизации.

Проект - web приложение - очень масштабное,  есть тонны бизнес схем и логики и к сожалению, полностью отсутствует автоматизация тестирования. Самая главная проблема - много сценариев на 30 -50 шагов. То есть нужно сделать все предыдущие шаги, чтобы дойти до конечного  и считать что сценарий пройден,

У меня есть небольшой опыт написания автотестов (год), используя javascript + cypress, другие фреймворки пока не пробовал. И так как это было на добровольных началах, получилось много огромных, зависимых друг от друга тестов. Сейчас же к этому хотелось бы подойти более осмысленно и ответственно, но возникают вопросы:

1. Как в таких сценариях таскать кучу данных с первого шага и до конца теста, насколько это правильно и не противоречит ли вообще BDD подходу написания сценариев, так как в каждом сценарии надо проверять не только скажем, наличие какого-то поля, но и возможность заполнить это поле, потому что его необходимо заполнить, чтобы была возможность двигаться дальше по сценарию и т.д.

2. Можно ли заменить UI тесты, какими-то другими, которые тоже будут хорошо покрывать необходимый функционал, но при этом будут более легко поддерживаемыми и менее громоздкими и тяжелыми

Я уже подозреваю, что автоматизация тестов при помощи эмуляции пользователя, это на самом деле и не автоматизация по большому счету. Это все равно, что на автомобильном конвейере у робота было бы пять пальцев, и он бы брал отвертку, вставлял в нее насадку, и придерживая мизинцем гайку, закручивал болт. Это смешно.

А ведь логично было бы иметь один-два теста в бот-стиле, которые бы проверяли корректность работы UI, а тест логики был бы уже совсем другой песней.

Подскажите какие-нибудь подходы для решения данной проблемы, может быть у кого-то был опыт решения подобных ситуаций.