Сообщение Re[88]: Что такое Dependency Rejection от 06.03.2024 8:34
Изменено 06.03.2024 8:51 ·
Re[88]: Что такое Dependency Rejection
Здравствуйте, Sinclair, Вы писали:
S>·>Говорил, цитирую: чудесные вещи типа "после того, как сделал var u = service.CreateUser(...), нужно выждать не менее 5 минут перед service.UpdateUser(u, ...)".
S>Это я говорил.
Ой, прошу прощения, я перепутал.
S>Это — реальный случай: парни, которые реализовывали API, завели его в ActiveDirectory с round-robin.
Перепутал наверное потому, что эти парни с той же логикой что и у Pauel — подменили синхронный код асинхронным с eventual consistency — и делают вид что всё в порядке, так и должно работать, "нефункциональное требование" в API, и никакие тесты у них наверняка не упали.
S>А вот если подождать 5 минут, то скорее всего UpdatePassword сработает, потому что пройдёт репликация AD, и все контроллеры этого пользователя увидят.
Да, именно что "скорее всего". В общем явная лажа в дизайне, даже неясно как consistency обеспечить хотя бы eventual.
S>Как вы такие вещи будете ловить при помощи моков — я так и не понял.
Я же рассказал — такое ловится конформационными тестами — небольшие быстрые тесты, которые дёргают "ихнее API" и ассертят результаты, проверяют на адекватность assumptions, сделанные в моках. Ловить такое в e2e вида "выполняется (медленный!) UI workflow с навигацией от логина" — можно только в простых случаях.
S>·>Говорил, цитирую: чудесные вещи типа "после того, как сделал var u = service.CreateUser(...), нужно выждать не менее 5 минут перед service.UpdateUser(u, ...)".
S>Это я говорил.
Ой, прошу прощения, я перепутал.
S>Это — реальный случай: парни, которые реализовывали API, завели его в ActiveDirectory с round-robin.
Перепутал наверное потому, что эти парни с той же логикой что и у Pauel — подменили синхронный код асинхронным с eventual consistency — и делают вид что всё в порядке, так и должно работать, "нефункциональное требование" в API, и никакие тесты у них наверняка не упали.
S>А вот если подождать 5 минут, то скорее всего UpdatePassword сработает, потому что пройдёт репликация AD, и все контроллеры этого пользователя увидят.
Да, именно что "скорее всего". В общем явная лажа в дизайне, даже неясно как consistency обеспечить хотя бы eventual.
S>Как вы такие вещи будете ловить при помощи моков — я так и не понял.
Я же рассказал — такое ловится конформационными тестами — небольшие быстрые тесты, которые дёргают "ихнее API" и ассертят результаты, проверяют на адекватность assumptions, сделанные в моках. Ловить такое в e2e вида "выполняется (медленный!) UI workflow с навигацией от логина" — можно только в простых случаях.
Re[88]: Что такое Dependency Rejection
Здравствуйте, Sinclair, Вы писали:
S>·>Говорил, цитирую: чудесные вещи типа "после того, как сделал var u = service.CreateUser(...), нужно выждать не менее 5 минут перед service.UpdateUser(u, ...)".
S>Это я говорил.
Ой, прошу прощения, я перепутал.
S>Это — реальный случай: парни, которые реализовывали API, завели его в ActiveDirectory с round-robin.
Перепутал наверное потому, что эти парни с той же логикой что и у Pauel — подменили синхронный код асинхронным с eventual consistency — и делают вид что всё в порядке, так и должно работать, назвали это как "нефункциональное требование" в API, и никакие тесты у них наверняка не упали.
S>А вот если подождать 5 минут, то скорее всего UpdatePassword сработает, потому что пройдёт репликация AD, и все контроллеры этого пользователя увидят.
Да, именно что "скорее всего". В общем явная лажа в дизайне, даже неясно как consistency обеспечить хотя бы eventual.
S>Как вы такие вещи будете ловить при помощи моков — я так и не понял.
Я же рассказал — такое ловится конформационными тестами — небольшие быстрые тесты, которые дёргают "ихнее API" и ассертят результаты, проверяют на адекватность assumptions, сделанные в моках. Ловить такое в e2e вида "выполняется (медленный!) UI workflow с навигацией от логина" — можно только в простых случаях.
S>·>Говорил, цитирую: чудесные вещи типа "после того, как сделал var u = service.CreateUser(...), нужно выждать не менее 5 минут перед service.UpdateUser(u, ...)".
S>Это я говорил.
Ой, прошу прощения, я перепутал.
S>Это — реальный случай: парни, которые реализовывали API, завели его в ActiveDirectory с round-robin.
Перепутал наверное потому, что эти парни с той же логикой что и у Pauel — подменили синхронный код асинхронным с eventual consistency — и делают вид что всё в порядке, так и должно работать, назвали это как "нефункциональное требование" в API, и никакие тесты у них наверняка не упали.
S>А вот если подождать 5 минут, то скорее всего UpdatePassword сработает, потому что пройдёт репликация AD, и все контроллеры этого пользователя увидят.
Да, именно что "скорее всего". В общем явная лажа в дизайне, даже неясно как consistency обеспечить хотя бы eventual.
S>Как вы такие вещи будете ловить при помощи моков — я так и не понял.
Я же рассказал — такое ловится конформационными тестами — небольшие быстрые тесты, которые дёргают "ихнее API" и ассертят результаты, проверяют на адекватность assumptions, сделанные в моках. Ловить такое в e2e вида "выполняется (медленный!) UI workflow с навигацией от логина" — можно только в простых случаях.