Я имел в виду именно украинские аутсорс-проекты (то что заказчики из Китая или Швеции или Израиля или ещё откуда зааутсорсили в Украину). Я по-прежнему не убеждён что это сколь-нибудь общая задача.

(интереса ради) Допустим у вас есть этот прогресс-бар с иконками.

Стадий для "всплытия" три: Preparing, Doing и Finished.  На каждой стадии отрисовывается что-то вроде тултипа с одной из вышеупомянутых.

Как Вы себе таки представляете интерфейс "shouldBe" ... для такой проверки? Отловит ли этот интерфейс если я поменяю Finished и Doing?

Чего я этим примером пытаюсь доказать, так это что для кастомных проверок лучше писать кастомные решения, а не искать "один размер подходит всем".

Как я и говорил, я с вебом не работаю. Просто видел веб диспетчерские аэропорта, полицейские приборки по реагированию на вызовы, контроль умного дома, точнее умный офис. Вот там задачи вполне подходят под мое описание, постоянно что-то мигнет, появится и т.д.

То что оно мигнёт и появится не значит что оно так тестируется. Вполне возможно что тесты разбиты на две части "послать сигнал на тестовое АПИ -- получить попап", "послать серию сигналов  на тестовое АПИ -- получить _определённую_ серию попапов".

Ваша задумка по-моему усложняет сущности.

Мы можем "ждать серию локаторов" и обрабатывать их, и узнать что были локаторы.

Мы можем "ждать серию текстов элементов" и обрабатывать тексты, и узнать что они были.

Но автор библиотеки может конкретно устать придумывая интерфейс для связывания локаторов по списку с надписями на тултипах. Или с иконками, и пр.

Поэтому я сторонник "кастомной задаче кастомную реализацию".

Я пока склоняюсь к мнению, что такой тест будет ненадёжным и неполным.

Например, что если ваши попапы появляются, но всего на 5 мс? Тогда тест будет зелёным, а юзер ничего не увидит.

По-моему, идеалогически правильный тест был бы такой:
1. Сэмулировал событие, по которому попап должен появиться.
2. Проверил, что попап появился.
3. Сэмулировал событие, по которому попап должен исчезнуть.
4. Проверил, что попап исчез.

Простой. Линейный. Управляемый.

Независимо от веб/не веб, селенид/не селенид, аэропорт/порносайт.

На 5 мс никто попап делать не будет, а вот на секунду вполне жизненно. Но даже при 5 мс тест асинхронка успеет его отловить, страница текста современным процессором раз 5 за миллисекунду распарсится

Так я же об этом и говорю. Тест увидит попап за 5мс и будет зелёным. А реальный юзер не увидит и будет красным.

Доброе утро, коллеги. Небольшой вопрос. TDD это относиться только к автоматизированным юнит тестам?

имеете в виду правильно ли что по тдд пишут только юнит тесты перед|вместе с разработкой?

Необязательно.

Вопрос в том что это относиться только к автоматизации или когда мы пишем тест кейсы до начала разработки это тоже TDD

тдд к автоматизации не относится, это техника разработки через тестирование, а не техника тестирования. Да и в автоматизации крайне редко пишут юнит тесты, в основном e2e через селениум, отсюда и столько вопросов по этой тулзе)

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

код девелопера не станет от этого лучше, а автоматизатор потратит кучу времени своего и девелопера, чтобы разобраться в коде, и написать монструозные юниттесты на монструозный код 🙂

Они там такого понапишут))

они же и мужчинами бывают

редко, правда

у вас тут всегда так скучно?