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

[mazzy]

Цитата:

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

А еще есть книжка Эффекстивная работа с унаследованным кодом там как раз про то, как писать тесты для говнокода.

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

Как я уже говорил в самом начале этой ветки, для dynamics продуктов это предположение неверное.
Большинство приемов связанных с расщеплением, охватом не работают.
(см. приложенные скриншоты)

Так в аксапте нельзя менять сигнатуры методов, которые находятся в sys-слоях. Можно только расширять сигнатуры. Что и делается параметрами по умолчанию. Откуда собственно и появилась ветка.

Причем нельзя менять не только клиентам и партнерам. Нельзя менять и самому майкрософту, чтобы не потерять совместимость кода.

Поэтому для Аксапты нужны адаптированные методы.
Но пока я вижу только советы: тестировать только свои изменения. Критерий - здравый смысл.
Что ж, и такие советы тоже не так уж и плохи. Спасибо.

Ближайший аналог:
разработка с закрытыми dll или com-компонентами.
В свой проект вы можете добавить закрытый код. Но не можете его изменить.
Вы можете создать свой охватывающий объект. Но не можете изменить поведение другого стандартного кода, который использует закрытый код (вернее можете. но выполнив закат солнца вручную)

и скорее нужно искать приемы разработки с подобными закрытыми компонентами.

Создал новую ветку
Как правильно вести разработку в условиях, когда часть кода закрыта от изменения - Sys-слой в аксапте, закрытые codeunit в навике, extensions в MS CRM

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