но делать так чтобы их могли писать люди далекие от компьютеров

это имхо не очень

далее поверх этих pageobject есть некий интерпретатор который дергает методы с нужными параметрами

Scenario: Gift card on large purchase When I purchase product with price 100 which is listen as premium product Then I should receive gift card on 10% from order amount

Так, ты опять все путаешь

при этом описывать свои требования в given, when, then бизнесу в трекере это хорошая привычка

вот тебе пример

поверх этого текста генерируется

тест

не генерится

тогда норм если так описано где то

я говорю о случаях когда поверх таких штук

генерится тест

который исполняется

и говорит что тот что тут написано выполняется

ой рано

Да, каждому степу в соответсвие ставится некай функция

Некое действие

набор этих функций это Pageobject о котором я говорил

выше

Нет

Это не pageobject

ок

Зачем тебе вообще ui

Чтобы тестить сценарий Сергея?)

чтобы открыть страницу с товаром

положить товар в корзину

Зачем?

оплатить товар

Ты можешь это сделать без ui

и по итогу получить gift card

могу но нахера такой тест?

бизнесу плевать если бэкенд отработал а на фронте все свалилось к хуям

Чтобы проверить бизнес-логику)

бизнесу нужен продукт в целом

чтобы продукт (приложение) соответствовало его требования

целиком

Д - декомпозиция

Тесты тв пишешь для себя

юнит тесты

А не для бизнеса

бизнесу плевать если бэкенд отработал а на фронте все свалилось к хуям

а у тебя такое часто бывает?) давай рассуждать, почему это может произойти

Для бизнеса во вторую очередь т.е.

ну например косяк в том что не корректно настроен smtp

это бэкенд

ок

косяк в том что кнопка оплатить не нажимается на фронте из за верстки

если благородные доны решили обсудить аксептанс тесты и селениум, то пожалуй упомяну http://www.nightmarejs.org/ который мне пришелся по нраву, использую теперь для приемочных тестов всех проектов, в т.ч. похапе

это косяк фронта

например верстали в fullhd а проверить надо в 1024х768

1. нарушен контракт между бэком и фронтом - есть масса способов чекать это. Могу рассказать отдельно как я делаю. 2. сломана инфраструктура. Наши тесты об этом не узнают. 3. косяк из-за верстки (поползна) - всеравно автотестами не покрыть за адекватные деньги и ты это не выявишь. Но опять же у меня есть примеры когда мы делали что-то вроде краулера который тупо бегал по страничкам и делал скриншеты в куче браузеров (ну и на мобилках мобильные апки так тестили)

и там наехало что то на кнопку, херовао конечно

масса этих способов

это трудозатраты

ты такие вещи никогда не покроешь тестами.

да ладно

и верить в то что unit test with 100% code coverage это фантастика

и что функциональный тест по оплате тоже еще написан дополнительно

1 день работы и у тебя готова хрень которая пробегает на 10-ти девайсах по всем 50-ти скринам твоей мобильной апы и делает скриншеты. Еще день и у тебя еще и работает сравнение оных.

к сожалению это суровая реальность некоторых проектов

мне кажется проекты сами себя загнали в такое положение

ну и я так и не понял твоей позиции

сравнения скриншотов отдельная песня

автотесты лож?

чтобы тебе описать этот косяк в тесте тебе надо с ним столкнутся

автотесты хорошо

чтобы тебе описать этот косяк в тесте тебе надо с ним столкнутся

какой именно косяк?

если ты фронтендер то ты рано или поздно в первые месяцы своей карьеры сталкнешься с фактом что верстка бывает едет

ERROR: S client not available

что на кнопку наехала верстка

так бизнесу плевать же кто виноват

что на кнопку наехала верстка

штука которая бегает по страничкам и тупо делает скриншеты детектит где-то 80% багов с версткой обычно

фронт или бэкенд

20% - экслорейшен тестинг и от этого никак не уйти

фронт или бэкенд

я фулстэк, так что и то и то делаю я) давай без разделения

если у тебя фронтэнд это тупо UI то там нет необходимости тестить бизнес логику

e2e тесты это хорошо, и покрыть ими самый критичный функционал штука полезная

но оно не выявит "верстку поехавшую"

Короч, проблема верификации аппы селениумом в том, что это долго в плане запуска тестов, хрупко вплане поддержки

долго насрать

Не знаю даже что больнее обычно

вообще не проблема

долго насрать

не насрать

Очень большая проблема

вообще не проблема

если твои тесты отрабатывают за 15 минут, ты не будешь запускать их чаще чем раз в час.

если твои тесты отрабатывают пол часа - ты будешь их запускать пару раз на дню

Час - пару раз в неделю)

если твои тесты отрабатывают по 4 часа (или 20 минут если их распаралелить) и они прогоняются в бесконечном лупе на CI сервере то локально ты их точно запускать не будешь и порой будешь узнавать что что-то сломал только после пуша

ну и иногда это раз два в день

как ваш селениум с ангулярами работает?

как ваш селениум с ангулярами работает?

хз, мы протрактор юзаем

Protractor же

еще раз я утверждал что в большинстве случаев не требуется разрабатывать отдельный язык, которым должны пользоваться менеджеры, чтобы описать то что они хотят

а как он с асинхроном работает?

Protractor же

Он даж промисы пнгулярские ждет

еще раз я утверждал что в большинстве случаев не требуется разрабатывать отдельный язык, которым должны пользоваться менеджеры, чтобы описать то что они хотят

менеджеры не нужны

ок заказчики

а как он с асинхроном работает?

Там норм интеграция с ангуляром

аналитики

кто там у вас)

Он даж промисы пнгулярские ждет

а, так не интересно