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

S>·>В нормальной ситуации — использовать коллекцию, которая не допускает null-элементы (кидает NRE например, при попытке добавить таковой) — чтобы обнаруживать косяк в момент его возникновения, а не потом когда-нибудь, если повезёт.
S>Как по мне, подход в стиле "задача не решается легко == косяк в дизайне" годится только для сферического дизайна в вакууме.

S>В реальной жизни
S>...
S>Так вот, когда пишут код без оглядки на подобные ограничения, вечно получается абсолютно неадаптированное к реальной жизни решение. Не надо так делать
Конечно, в реальной жизни есть разные задачи. Ты, думаю, прекрасно понимаешь, что одни и те же задачи можно решать используя разные инструменты. Так вот, мой тезис в том, что инструмент "ассерты" — плохой инструмент, вместо него в подавляющем большинстве случаев желательно выбирать другие — исключения, явные проверки, логгеры, тесты, рефакторинг, редизайн и т.д.
Это как "сопли" плохой материал для скрепления предметов, лучше взять клей или гвозди.

S>·>Почему не вариант? Это говорит о том, что ассерт написать проще, чем ютест. А это говорит о том, что ютесты пишутся сложно. А это говорит о том, что код не самого лучшего качества.
S>См выше про сферический дизайн. Довод "это у вас код неправильный" — первейший признак сабжа.
S>Если коротко, то ассерты ортогональны тестам. Тесты документируют и проверяют контракт отдельных кусков кода. Ассерты обеспечивают соблюдение инвариантов для _всех_ реальных сценариев использования. Каждый инструмент решает свою задачу, смысл тут спорить-то?
Тесты должны проверять _все_ реальные сценарии использования. Как минимум те, до которых додумался программист (а раз он додумался до ассерта, то значит и до теста мог додуматься).

S>>>Или как в нашем случае — чтоб воспроизвести баг, нужно продублировать весь сценарий, т.к. итоговая ошибка вызвана мелкими логическими несостыковками в 3 независимых кусках кода. Ок, воспроизвели, починили, завели тест, всё зелёное. Какие гарантии, что эта же ошибка не воспроизведётся при другой комбинации условий и как этот момент вообще отловить?
S>·>Я не понял из описания issue взаимосвязь с ассертами. Можно поподробнее?
S>Очень просто — наш проект упал с ассертом "строка в .csv содержит неэкранированный разделитель", текущая культура Central Kurdish, разделитель списка — ؛. Заметь, что для этого нам не пришлось писать отдельный тест для csv, перебирать все культуры (эта, к примеру, появилась в восьмёрке, пока CI-сервер был на 2012-м — фиг бы поймали), просто прогнали интеграционный тест и он нашёл штуки три похожих ошибки.
А почему "строка в .csv содержит неэкранированный разделитель" нельзя проверить авто-тестом? Почему ассерт написали, а тест — нет?
Поменял культуру — програл test suite — посмотрел что упало.

S>Раз такое дело — проверил соседние проекты, нашёлся аналогичный баг в BenchDotNet, в CodeJam тоже поправить надо будет, если попросят произвольные разделители.

S>·>И как этот код будет работать, если вдруг попадёт на какой-нибудь server side?
S>Никак. Поэтому все пишут свои ассерты
Да перестаньте их уже писать!