Дякую за розгорнуту думку.
Ваша стратегія, до речі, дуже близька до нашої: пріоритети, impact analysis і дослідницьке тестування на решту. Різниця радше в тому, яку вагу несе кожна частина.
Уточню лише два моменти.
Регресія у нас нікуди не зникла, вона проводиться турами. Ми вивели з експлуатації скрипти, які з регресії в регресію мали сталий набір перевірок. Навіть параметризований набір лишається рамками, просто ширшими, а нам потрібно було саме вийти за рамки.
Дякую за думку. E2E у нас є і працюють саме так, по застосунку і з перевіркою бізнес-результату. Але навіть добрий E2E перевіряє лише ті сценарії, які хтось заздалегідь придумав, а в проді трапляються якраз ті, які ми не завжди могли передбачити.
Transactional outbox і Temporal нормальні підходи, але вони не прибирають потребу в reconciliation із самою біржею. Ордер уже може бути виконаний зовні, а локальний state ще не зафіксований. Тому recovery та idempotency у мене винесені в окремий шар.
Вітаю, Романе. Дякую, що знайшли час на детальний розбір, відео подивився повністю.
Почну з головного, бо звідси ростуть майже всі зауваження. Стаття про підхід до дослідницького тестування.
Непогано, є куча коду і купа тестів :) Проблеми з консистентністю вирішують на рівні архітектури штуками типу transactional outbox / temporal
Головне питання — що по пнл на лайв трейдах за півроку/рік чи скільки воно крутиться в проді?
Питання в іншому: навіщо тягнути UI-автоматизацію далі, якщо покрити все нею однаково неможливо. Кількість конфігурацій і можливих дій користувача зростає швидше, ніж ви встигаєте писати тести.
Біль був не в розкладі, а в тому, що покриття було сталим: тисяча кейсів щоразу перевіряла те саме
Ну так це і є регресійним тестуванням, ні? А тепер його у вас немає.
А те, що пропускається в прод, у скриптах не описане взагалі.
Так добавте.
По кількості та величині коментів стаття імхо залетіла. Але технічно імхо це провал так було робити, локалізацію тестити руками на різних темах, браузерах та ос.
Коментарі