Comments on Систематизация автоматизации: Defensive Design. Откуда берутся сбои

приятно, что можно подробно почитать об интересующ...

2009-05-12T12:35:00.000+03:00

приятно, что можно подробно почитать об интересующем вопросе, спасибо автору!

Более легковесный вариант: http://www.codeproject....

2009-04-07T09:15:00.000+03:00

Более легковесный вариант: http://www.codeproject.com/KB/cs/designbycontract.aspx, только нужна определенная сила воли, чтобы использовать в проектах :).
Большой плюс в таких библиотеках и оболочках - наглядность исходников.
Здесь можно посмотреть хороший пример использования DesignByContract - "NHibernate Best Practices with ASP.NET, 1.2nd Ed.", http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspx?msg=1527549#xx1527549xx

Еще одна занятная вещь: Code Contracts.

2009-04-06T15:07:00.000+03:00

Еще одна занятная вещь: Code Contracts.

Непосредственно для логирования удобнее использова...

2009-04-06T14:34:00.000+03:00

Непосредственно для логирования удобнее использовать более развитые вещи вроде log4net. А вот наглядно увидеть модальный диалог на ранних стадиях отладки (малой кровью), причем из любого потока выскочит (с умолчательной конфигурацией) бывает полезно.

Исключительно полезная вещь Debug.Assert, конечно ...

2009-04-06T14:12:00.000+03:00

Исключительно полезная вещь Debug.Assert, конечно при умелом использовании.
Навскидку дает дополнительную информацию о сбоях внутри алгоритмов и их ЧАСТЕЙ при проходе тестов и ручной отладке. Исключительно важно для многопоточных(многопроцессных) приложений в процессе их отладки и юниттестирования. Т.к. в простых и комплексных тестах иногда бывает достаточно сложно судить об успешности его прохождения (критерии или сложны или не совсем очевидны). Поэтому прогон при дебаговой конфигурации даст как минимум отсутствие результата на выходе (сработает Debug.Assert) за отведенное время, а нюансы увидим в логе. Или другой пример - логика конечных автоматов, допустимые переходы состояний я всегда проверяю через Debug.Assert. В сложных системах без пользовательского интерфейса иногда бывает чуть ли не единственным признаком того что что то идет не так, т.к. зачастую "защитный" код таких систем позволяет сохранить работоспособность и даже выдать результат, который не всегда рационально разбирать.
Несколько соображений которые я держу в голове при использовании Assert.
Через него проверяться должна ТОЛЬКО ЛОГИКА РАБОТЫ АЛГОРИТМА или его частей, и не в коем случае пользовательский ввод или информация пришедшая извне (другой модуль, система, источник). А вот после обработки верфикатором и возможно исправления его алгоритмами обработки ввода самое милое дело проверить эти самые алгоритмы через Assert (часто они просты, тест писать излишне, а проверить нужно). Юниттесты на все нюансы работы алгоритма и его частей не напишешь, а рефакторить до бесконечности тоже не всегда разумно.
И еще не забывать, что кроме Debug.Assert, есть и Trace.Assert.
Debug.Assert иногда можно нагрузить тяжелыми проверками, которых не будет в релизной конфигурации.
Направление вывода Debug.Assert можно декларативно менять через конфиг, т.е., например, писать в лог файл.

Спасибо за столь ценную информацию.

2009-02-13T16:48:00.000+02:00

Спасибо за столь ценную информацию.

Кроме того, не стоит забывать о различной природе ...

2009-02-03T12:47:00.000+02:00

Кроме того, не стоит забывать о различной природе этих ассертов. TDD сродни синтетическим тестам, против тестов, которые работают в рантайме на живых данных.

Одно другому не мешает, на самом деле. Особенно, к...

2009-02-03T12:45:00.000+02:00

Одно другому не мешает, на самом деле. Особенно, когда речь идет о валидации данных из внешних источников.

Но я бы пожалуй согласился, что Debug.Assert отойдет. Но не в пользу TDD, а в пользу Design by Contract, как более строгой и стройной форме этих самых ассертов.

Еще один момент про Debug.Assert. Имхо эта практик...

2009-02-03T12:37:00.000+02:00

Еще один момент про Debug.Assert. Имхо эта практика будет все менее популярна в связи с внедрением в массы TDD (юнит тестов). ТДД покрывает бизнес-метод тестами, в т.ч. тестами на то, как метод будет реагировать на некорректные значения параметров. Т.е. ТДД стимулирует исправлять код метода, чтобы тесты проходили. А Дебаг.ассерт - это своего рода "юнит тест лайт", внедренный в код метода, т.е. это не стимулирует делать код лучше, а только засоряет код описаниями, когда методу будет фигово :-)
Пример: Функция, которая делит х на у:
private decmal Div(decimal x, decimal y) {
return x/y;
}

Вариант_1 с изменением кода для Дебаг.Ассерт:
надо добавить в метод код: Debug.Assert(y != 0);

Вариант_2 с изменением кода для юнит тестов:
надо добавить в метод код: if (y == 0) {throw new MyBussinesException()};
+ добавить 2 юнит теста: нормальное деление на y!=0 и там, где кидается бизнес эксепшн.

Имхо, 2-ой вариант намного лучше: а) повышается качество исходного кода б) исх. код не замусоривается лишним кодом в) в случае неправильного использования метода узнаем об этом мы (разработчики) на стадии прогона юнит-тестов, а не кастомеры в лайф версии.

Есть мнение в ИТ, что дебаг.ассерт юзают крутые гу...

2009-02-03T11:44:00.000+02:00

Есть мнение в ИТ, что дебаг.ассерт юзают крутые гуру, но никто из опрошенных гуру эту информацию не подтвердил, но и не опроверг :D