Pull to refresh
2
0
Send message

race condition-ы здесь в широком смысле – как в коде, так и при работе с БД. В первом примере мы рассматриваем гонку 2 корутин за изменение переменной в памяти, а в последнем примере это конкурентные апдейты строки в БД.

То есть решающее значение имеет порядок вызовов, а не задержки обработки

Все так, но порядок выполнения операций зависит от задержек. Например в тестах race condition может не проявляться, а в проде под боевой нагрузкой начнет стрелять из-за изменившихся задержек.

Насколько релевантны окажутся результаты тестов при изменении, например, движка базы?

Идея с полным перебором всех возможных последовательностей как раз решает эту проблему – мы пытаемся исключить влияние случайных задержек.

До формальной верификации мы еще не доросли :) Для обычной продуктовой разработки это слишком долго и дорого относительно цены ошибки. Но может быть придем и к TLA+ если будет подходящий юзкейс

Смотря что тестировать – в наших сервисах обычно много работы с БД, и это как раз то что хочется покрывать тестами в первую очередь. Максимум что мы можем сделать для ускорения – потюнить настройки персистентности постгри. Ну и тесты распараллелить конечно.

Information

Rating
Does not participate
Registered
Activity