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

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

S>·>Если "ошибки быть в принципе не может" — тогда и проверка не нужна. А раз страхуешься, значит неверно что "ошибки быть в принципе не может". Ты уж определись.
S>Ошибки "в принципе быть не может" на текущей codebase. Как, к примеру, ловить некорректные значения, возвращённые сторонним кодом?
Корректно обрабатывать — кидать исключение, например.

S>Писать на каждый случай отдельный тест — не вариант, т.к. надо точно воспроизвести интересующий нас сценарий, а не просто проверить "ну вот сейчас нормальное значение пришло, значит всё ок". С воспроизведением получим кучу лишнего кода, который ещё и синхронизировать с тем, что в основном проекте лежит.
Почему не вариант? Это говорит о том, что ассерт написать проще, чем ютест. А это говорит о том, что ютесты пишутся сложно. А это говорит о том, что код не самого лучшего качества.

S>·>Ассерты говорят от дыре в дизайне, которая не позволяет написать простой юнит-тест для того же условия.
S>·>Ну раз ассерт догадались написать, значит и ютест можно было написать.
S>Ну эт только в мелких проектах работает. В боль-менее крупных сплошь и рядом нет нужных тестов. Написать их не проблема, но по факту никто ими не озаботился — авторы проекта сценарий не предусмотрели или он для них не актуален. Или с их точки зрения поведение правильное и ошибка из-за некорректной настройки — это проблемы клиента. Чего в подобных ситуациях делать?
Почему авторы таки озаботились ассертом, но ютестом озаботиться не смогли?

S>Или как в нашем случае — чтоб воспроизвести баг, нужно продублировать весь сценарий, т.к. итоговая ошибка вызвана мелкими логическими несостыковками в 3 независимых кусках кода. Ок, воспроизвели, починили, завели тест, всё зелёное. Какие гарантии, что эта же ошибка не воспроизведётся при другой комбинации условий и как этот момент вообще отловить?
Я не понял из описания issue взаимосвязь с ассертами. Можно поподробнее?

S>Ну, т.е. два варианта: или ставим ассерт, или рассказываем про "ассерты не нужны" и "да всё ок, это у вас дыра в дизайне".
Третий вариант — пишем тест.

S>·>Если ассерты работают всегда, то почему это ассерты? Под ассертами подразумевается код отключаемый в релизе. А если их не отключают — то значит они используются не по назначению.
S>А какой смысл придумывать отдельный термин для "что-то типа ассертов, только в релизе работает"?
"displays a message box" — гы-гы. В духе майкрософт. Программисткая лажа лезущая прямо в морду несчастных юзеров. Особенно замечательно подойдёт для "код из нагруженного участка".
И как этот код будет работать, если вдруг попадёт на какой-нибудь server side?

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

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

S>·>Если "ошибки быть в принципе не может" — тогда и проверка не нужна. А раз страхуешься, значит неверно что "ошибки быть в принципе не может". Ты уж определись.
S>Ошибки "в принципе быть не может" на текущей codebase. Как, к примеру, ловить некорректные значения, возвращённые сторонним кодом?
Корректно обрабатывать — кидать исключение, например.

S>Писать на каждый случай отдельный тест — не вариант, т.к. надо точно воспроизвести интересующий нас сценарий, а не просто проверить "ну вот сейчас нормальное значение пришло, значит всё ок". С воспроизведением получим кучу лишнего кода, который ещё и синхронизировать с тем, что в основном проекте лежит.
Почему не вариант? Это говорит о том, что ассерт написать проще, чем ютест. А это говорит о том, что ютесты пишутся сложно. А это говорит о том, что код не самого лучшего качества.

S>·>Ассерты говорят от дыре в дизайне, которая не позволяет написать простой юнит-тест для того же условия.
S>·>Ну раз ассерт догадались написать, значит и ютест можно было написать.
S>Ну эт только в мелких проектах работает. В боль-менее крупных сплошь и рядом нет нужных тестов. Написать их не проблема, но по факту никто ими не озаботился — авторы проекта сценарий не предусмотрели или он для них не актуален. Или с их точки зрения поведение правильное и ошибка из-за некорректной настройки — это проблемы клиента. Чего в подобных ситуациях делать?
Почему авторы таки озаботились ассертом, но ютестом озаботиться не смогли?

S>Или как в нашем случае — чтоб воспроизвести баг, нужно продублировать весь сценарий, т.к. итоговая ошибка вызвана мелкими логическими несостыковками в 3 независимых кусках кода. Ок, воспроизвели, починили, завели тест, всё зелёное. Какие гарантии, что эта же ошибка не воспроизведётся при другой комбинации условий и как этот момент вообще отловить?
Я не понял из описания issue взаимосвязь с ассертами. Можно поподробнее?

S>Ну, т.е. два варианта: или ставим ассерт, или рассказываем про "ассерты не нужны" и "да всё ок, это у вас дыра в дизайне".
Третий вариант — пишем тест.

S>·>Если ассерты работают всегда, то почему это ассерты? Под ассертами подразумевается код отключаемый в релизе. А если их не отключают — то значит они используются не по назначению.
S>А какой смысл придумывать отдельный термин для "что-то типа ассертов, только в релизе работает"?
"displays a message box" — гы-гы. В духе майкрософт. Программисткая лажа лезущая прямо в морду несчастных юзеров. Особенно замечательно подойдёт для "код из нагруженного участка". Вот подумай, сидит бухгалтерша, тыкает кнопки и вдруг у неё вылазит "Column editor supposed to be a ComboBoxEdit". И чё?!
И как этот код будет работать, если вдруг попадёт на какой-нибудь server side?