Здравствуйте, Sinix, Вы писали:
S>>>Дык какие же? Помимо юнит-тестов в смысле.
S>·>Почему "помимо"?
S>Потому что есть класс ошибок, для которых писать нормальный тест невыгодно, а частичный тест ничем не поможет. (Например, код используется в десятке мест, надо гарантировать, что ни одно из них не передаёт, скажем, 42).
Так ассерт не может в принципе "гарантировать, что ни одно из них не передаёт, скажем, 42". Он будет лишь что-то (не)делать, если 42 таки передалось.
А вот тесты — будут гарантировать: ведь ты явно выделил 42 как некий специальный случай, а значит для него будет специальный тест.
S>·>Кого настроишь — тот и будет следить. Лог-аппендеры при желании могут даже окошко могут нарисовать.
S>А зачем окошко-то? Ассерты здорового человека просто бросают исключение + дают возможность залогировать сработавшие ассерты.
А теперь, дети, посмотрите на ассерты майкрософта.
S>Логгер плох тем, что теперь любой тест должен этот логгер настраивать и проверять, иначе ошибка останется незамеченной. Если настроить так логгер по умолчанию — получаем всё те же ассерты, только ненадёжные. Повезёт — ошибка словится, пользователь перенастроил? Ну, не судьба.
Ну обычно ERROR уровень таки не оставляют незамеченным.
S>·>Мда, похоже, тут спор частично терминологический. Под ассертами понимаются обычно такие проверки, которые отрубаются в проде. А если это такие проверки, которые работают всегда и везде, кидая исключение, то они ничем неотличимы от обычных проверок типа if(x) throw Exception, кроме, может быть, синтаксиса.
S>А, это из плюсов, наверно, в наследство досталось. Глянь тут
Так там я это и прочёл:
When a program is deployed to production, assertions are typically turned off
Most languages allow assertions to be enabled or disabled globally, and sometimes independently. Assertions are often enabled during development and disabled during final testing and on release to the customer.
S>или тут. Везде основное свойство ассертов — "проверяет ожидания программиста", а не "не работает в релизе".
А ты сам-то читал?
Assertions should never stay in production code. If a particular assertion seems like it might be useful in production code, then it should not be an assertion; it should be a run time error check, i.e. something coded like this: if( condition != expected ) throw exception.
If you're even thinking of leaving assertions on in production, you're probably thinking about them wrong
Normally, you don't want users to see assertion messages in production code; assertions are primarily for use during development and maintenance. Assertions are normally compiled into the code at development time and compiled out of the code for production. For highly robust code, assert and then handle the error anyway.
S>>>·>А в дебаге он получит что-то лишь в том случае, если _догадается_ написать ассерт. А раз догадался написать ассерт — почему не написал тест?
S>>>Потому что далеко не всегда получается придумать способ нарушить ассерт на текущем коде, иногда это в принципе невозможно.
S>·>Если это и вправду "в принципе невозможно" — то накой тогда ассерт?
S>Ну вот смотри: пишешь ты код и видишь, что если вызвать метод DoWork() до метода Init() или после метода Clear(), то он натворит полную фигню. Смотришь код — везде всё норм, даже тест с моками есть. Оставляешь как есть — и в продакшне код творит полную фигню из-за бага сериализатора, который неправильно восстановил поле-структуру за десять вызовов по стеку от твоего кода. Не придумываю, реальный случай был лет так пять назад.
S>Не дешевле было просто ассерт поставить?
Лучше в DoWork вставить
if(!inited) throw Exception.
У тебя публичный контракт с тремя методами Init/DoWork/Clear — а соответственно любой пользователь класса может не следовать этому контракту, значит его надо явно проверять. То что у тебя на данный момент в коде нет таких пользователей это тебе не даёт право надеяться на авось — такой плохой пользователь может получиться позже — из-за неудачного рефакторинга или добавления новой функиональности, а в твоём случае такой пользователь был, но был неявный, из-за рефлексии в этом сериализаторе, видимо.
