Как правильно выполнять unit-тестирования методов с параметрами по умолчанию на ваш взгляд?

[mazzy]

Цитата:

Сообщение от belugin

Я не очень понял чем это концептуально отличается от тестирования той же функциональности, но выраженной в коде другими средствами?

здесь пропускаем слово модифицируем ))))

Цитата:

Сообщение от belugin

Почти вся разработка такая - мы не модифицируем код ни винды ни .NET FW

а здесь пропускаем слово тестируем. ))))

вуаля, ответ готов.
самое интересное, как всегда, не что сказано, а что пропущено. ))))

Цитата:

Сообщение от gl00mie

Стесняюсь спросить, все ли сотрудники Microsoft, причастные к разработке приложения Аксапты, в курсе, что нельзя так делать?

некоторые прорываются ))))

Цитата:

Сообщение от gl00mie

раньше в методе, скажем, 3-им по счету шел..
А теперь 3-им по счету идет новый стандартный флажок

убедил.
про майкрософт - согласен.
про "добавление параметров по умолчанию" - по прежнему считаю, что это очень распространенный подход в аксапте

Цитата:

Сообщение от gl00mie

По мне - умерла, так умерла: если надо существенно поменять сигнатуру стандартного метода, то надо это сделать - и по возможности использовать нормально типизированные параметры, а не безликие boolean-флажки, чтобы компилятор заметил несоответствия в вызывающем коде, а еще лучше, по-моему, вместо хрендцати параметров использовать data transfer objects (DTO), в которые можно добавлять новые свойства, не переделывая каждый раз сигнатуру вызываемого метода.

Да, согласен - лучше быть богатым и здоровым, чем бедным и больным.

А как это эффективно и правильно сделать в существующем инструментарии?
И с существующим унаследованным кодом?

Собственно тема как раз про это )

[belugin]

Цитата:

Сообщение от mazzy

здесь пропускаем слово модифицируем ))))

Чем отличается тестирование модифицированного кода со значениями по умолчанию от тестирования модифицированного кода другими средствами?

Цитата:

а здесь пропускаем слово тестируем. ))))

Оно в слове "Разработка"