B
запрос дёрнуть, или перехватить текущий
Size: a a a
2021 August 30
EB
да, но тут уже вопрос by design ты хочешь чтобы твои тесты работали с запросами в бекенду и его анализом или в кач-ве апдейт операций у тебя будут лейблы для автоматизации фронта которые любую асинхронность помогут причесывать
СС
представляю когда спиннеров будет 2 (и более) подряд)
СС
имхо - самый адекватный вариант из всех что здесь были. а лучше - вообще без спиннера
B
А сколько ждать? 5с? 10с?
EB
спиннер тут не представляется как что-то что тестируется, а как показатель того, что данные в таблице прососались и обновились, подозреваю
СС
столько сколько надо. а вот сколько это пусть уж сам решает
EB
поэтому ты видимо и не понял, что я говорил про колбеки и завязку на том же самом ивенте на странице, который данные грузит =)
S
А если выкинуть проверку спинера и просто сравнить 2 стейта таблиц? Если данные приходят в 1 запросе таблу, зачем спиннер тестить?
СС
а сами данные которые изменились не являются прямым показателем что данные изменились?)
AV
Из неупомянутого еще свой вариант такой: переделать спиннер на такой цикл - по акции: удаляемся из DOM, создаёмся, вертимся, остаёмся невидимым по окончании.
B
Если данные не изменились, то таблица может не перерисовываться. А но при этом нужно убедиться, что запрос улетел, ответ был получен и обработан.
EB
если ты знаешь, как они изменились, то отлично. но данные бывают разные
СС
например?
СС
открыл страницу, запомнил до. сделал действие. жду когда будет что то отличное от до. профит
B
Мое мнение: фиксируем событие, что запрос с фронта был, ответ получен, после чего спиннера нет, идем дальше)
AV
Ну и тест простой:
спиннер должен появится в доме и стать невидимым.
Вроде без оверхеда и дополнительных ожиданий
спиннер должен появится в доме и стать невидимым.
Вроде без оверхеда и дополнительных ожиданий
B
В идеале берём кипарис...
СС
это совершенно другой кейс
СС
и без перехвата или доп какой то логики на клиенте - это не проверить, здесь бесспорно. но рут вопрос был про другое