Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Вопрос же к тебе более общий — практика использования assert'ов в managed языках. Насколько я помню ты много раз писал на эту тему.

А чего там обсуждать-то?

Абсолютно стандартная практика: закладываешься на какой-то факт — напиши ассерт. Закладываешься, но считаешь, что "такого не может быть никогда" — напиши отладочный ассерт, сюрприз будет

Дальше ещё проще. Сработал ассерт — останавливаемся и разбираемся в обязательном порядке. Или правим баг в коде (с edit-n-continue можно править код, не прерывая отладки), или убеждаемся, что у нас косяк в дизайне, ставим временный костыль и заводим тикет на исправление.

Не сработал — тож замечательно. Потом сработает. Потому что ассерты работают всегда, а не только один раз в виде конкретного юнит-теста, и, соответственно, шансы словить ошибку у них на порядок больше. На порядок — эт не преувеличение, в том же CodeJam.PerfTests в основном ошибки ловились или интеграционными тестами, или ассертами (хотя их там мало довольно емнип). Простые юнит-тесты главным образом работали как способ обнаружения регрессий и после падения такого теста приходилось ещё разбираться, что именно пошло не так.

Такой подход экономит кучу времени, т.к. для сложного кода можно не раздербанивать кишки на кучу отдельных тестов, а просто прогнать интеграционные тесты для основных сценариев и проследить (через code coverage), что все потенциально проблемные места покрыты.


Вся инструментальная часть требует ровно двух вещей:
* возможность прервать выполнение при нарушении ассерта.
* при подключенном отладчике — немедленно остановиться в месте, где ассерт сломался.

Собственно всё, никакой managed-специфики тут нет.