SP
у меня BI команда в базе капошится :) так что у меня такие тесты есть потому что "это интерфейс такой")
Size: a a a
2021 May 24
A
так ведь SQL для людей придумывали) всё верно
SP
ну просто вот пример - у тебя есть запрос который меняет поле какое-то. И это поле нужно для UI. при этом это поле только админы видят. У тебя сразу надо разбираться а че кто когда кому. И лучше в базу сходить чем "мы тут в апишку поле добавили потому что для тестов надо".
ЗД
А вот ситуация, если тестируется 2FA через почту, как бы вы поступили?
Автотестеры гоняют в БД и оттуда берут 6-значный код и вводят его в форму. Тем временем, реальной отправки письма нет (driver = log).
Автотестеры гоняют в БД и оттуда берут 6-значный код и вводят его в форму. Тем временем, реальной отправки письма нет (driver = log).
SP
это как "добавлять геттеры только потому что в тесте надо как-то проверить".
SP
а если код захеширован? Шо тогда делать будете?
A
ты по-другому спроси. Если код не был захеширован, а через пару лет решили захешировать)
SP
не, это на тестирование влиять не будет) У секьюрников вопросы будут по самому факту что временные пароли не хэшированы. Ну мол вдруг будут бухтеть
A
если тесты лазят за кодом в базу - они упадут
DE
Функциональным это простительно, так как база рядом лежит.
Заморачиваться с отдельными интерфейсами актуально для приёмочных/E2E тестов, которые концептуально находятся снаружи приложения.
Заморачиваться с отдельными интерфейсами актуально для приёмочных/E2E тестов, которые концептуально находятся снаружи приложения.
SP
я к тому что вот driver=log - можно подсунуть свой драйвер и брать код из письма
SP
или еще как, или подменять генератор кодов в тестах
SP
много чего можно делать
SP
главный вопрос - "а какие риски ты хочешь закрыть?"
V
А кто вот отвечает за JSON сериализацию энтитей?
Или правильнее на чтение давать дтошники, которые имплементят JsonSerializable какой-нибудь, а на запись и бл уже юзать энтити?
Или правильнее на чтение давать дтошники, которые имплементят JsonSerializable какой-нибудь, а на запись и бл уже юзать энтити?
A
мне сложно улавливать разницу. я имел ввиду E2E как раз
DE
Правильнее отдельные DTO-шки
V
Хорошо. А в случае, когда после бизнес логики мне надо этот же объект отправить в другую апишку JSON'ом условным.
Допустим применить промокод к заказу. Мы через агрегат подпихиваем промокод, а потом нам надо в какой-нить PriceDiscountGateway отдать эту энтитю и получить обратно результат. Что в таком случае?
Допустим применить промокод к заказу. Мы через агрегат подпихиваем промокод, а потом нам надо в какой-нить PriceDiscountGateway отдать эту энтитю и получить обратно результат. Что в таком случае?
ЗД
Ну, получается так, что при E2E тестировании часто приходится идти на крайние меры: в случае 2ФА через почту — ловить реальные письма, доставать оттуда код и т.д.
По сути, E2E тесты должны запускаться на сборке приложения, аналогичной продакшну. Поправьте, если я не прав, опыта с E2E нет.
По сути, E2E тесты должны запускаться на сборке приложения, аналогичной продакшну. Поправьте, если я не прав, опыта с E2E нет.