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

[mazzy]

Цитата:

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

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

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

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

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

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

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

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

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

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

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

[gl00mie]

Цитата:

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

Как и все подобные книги, авторы исходят из предположения, что код можно и нужно менять. Как я уже говорил в самом начале этой ветки, для dynamics продуктов это предположение неверное.
Так в аксапте нельзя менять сигнатуры методов, которые находятся в sys-слоях. Причем нельзя менять не только клиентам и партнерам. Нельзя менять и самому майкрософту, чтобы не потерять совместимость кода.

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

protected Object dialog(DialogRunbase _dialog = null, boolean _forceOnClient  = false)

\Classes\RunBase\dialog в AX2012:

protected Object dialog()

Удаление параметров метода, пусть и имеющих значения по умолчанию, ведь не считается "расширением"?..

Цитата:

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

Можно только расширять сигнатуры. Что и делается параметрами по умолчанию.

С т.з. проекта, на котором есть кастомизации, добавление в сигнатуру метода на sys-слое нового параметра со значением по умолчанию точно так же приводит к потере совместимости кода - стандартного с кастомизациями. Потому что раньше в методе, скажем, 3-им по счету шел новый кастомный флажок boolean _skipЧегоНибудь = false, и код был допилен для передачи этого нового флажка. А теперь 3-им по счету идет новый стандартный флажок boolean _updateЧегоТоТам = true, и стандартный код местами явно передает значение этого нового стандартного флажка, и поди потом разберись, где в вызове 3-им параметром передается кастомный флажок, а где - стандартный...

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

Извините, что не в тему, наболело.

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

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

[belugin]

Цитата:

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

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

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

Цитата:

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

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