Как стать автором
Обновить

Комментарии 4

вы изобрели странную смесь unit тестирования и ui тестирования. Идея selenium и т.п. вещей, это тестирование взаимодействия со страницей, точно также, как это будет делать юзер.

У вашего подхода очень сильная связанность с имплементацией приложения, но при этом связь с html никуда не делась, вы также должны проверять что-то через DOM.
Проверка чего-то через DOM — это малая часть работы теста.
То, что Глеб (автор статьи в оригинале) называет App Action, по сути является precondition для теста, и правильно его делать самым быстрым способом. API, правка в БД, или функции самого приложения.
Я правильно понимаю, что после этой доработки тест не заметит, что из шаблона случайно удалили кнопку добавления элемента в список todo? Если да, то почему такой тест можно называть «сквозным»?
> Я правильно понимаю, что после этой доработки тест не заметит, что из шаблона случайно удалили кнопку добавления элемента в список todo?

Совершенно верно, однако на то, что кнопка Добавления элемента не пропадёт, должен будет другой тест. В итоге, если оба теста проходят, значит всё работает как и задумано.

Смотрите, если у вас есть тестовый сценарий «Удаление объекта», то для того, чтобы тест каждый раз мог удалить объект и тем самым проверить, что удаление работает корректно, тесту нужно сначала объект создать. Каким образом он будет создан — не столь важно.
Например, добавлен через БД или через API.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий