данные: неважно какие, главное что структурированные и документированные.
С нашей стороны эти данные на входе парсятся и валидируются, складываются во внутреннее представление этих PDU и дальше уже почищенные летят по системе.
Каким образом вы вот эту часть парсинга и валидации тестируете?
API нами не контролируется, и в нем иногда происходят изменения, которые нужно отразить в своем коде и затем протестировать, что правильно сформированные PDU правильно нашим кодом читаются и валидируются.
Руками следить за изменениями API и руками же дописывать тестовые PDU багоопасно, проверено на своем опыте. Что-то недоглядел, какой-то корнер-кейс промазал и вот у тебя, например, валидная по документации PDU на валидации падает в мусор.
Какую-то схему на своей стороне городить и по ней генерировать PDU для тестов -- в принципе, вариант, но тоже много бойлерплейта.
Пытаюсь сообразить элегантное решение и ничего в голову не приходит пока что.
к внешнему API схема есть?
а) автогенерация биндингов из спеки б) апи и биндинги к нему в одной репе и там же тесты соответствия
> Пытаюсь сообразить элегантное решение 1. Валидация должна быть строгой. 2. На падении валидации собирай структуру и где-то сохраняй (в моих проектах это в Sentry) 3. Добавляй это структуру в тест, когда чинишь С Максимом полностью согласен насчёт телеметрии и мониторинга процента ошибок
А у api есть способ запросить исторические данные? Если да, то можно например постоянно запрашивать какие-то определенные данные, и если формат ответа поменялся то сразу будет видно что и где и как поменялось.
Обсуждают сегодня