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

[belugin]

Надо написать такой набор тестов, чтобы написать по ним правильный код было легче чем написать неправильный. Например, проверить каждый параметр по отдельности на явно заданное значение и тот случай, когда они все вместе включены (если они должны быть связаны через && в запросе). Умолчания будут проверяться при проверке отдельных других параметров.

[mazzy]

Цитата:

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

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

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

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

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

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

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

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

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

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

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

[belugin]

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

Можно ввести какой-то свой API в виде отдельных фнукций для удобства (см мое первое сообщение в этом треде).

Цитата:

Ближайший аналог:
разработка с закрытыми dll или com-компонентами.

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

[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

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

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

Цитата:

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

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

[Raven Melancholic]

Вообще, вопрос, поднятый в теме так и просится разбиения на два:

1. Как тестировать методы с параметрами по умолчанию.
2. Как тестировать методы со множеством параметров.

Как раз приведенный пример не в полной мере соответствует заголовку темы. Про тестирование параметров по умолчанию имеет смысл говорить в случаях, когда в логике метода есть разные ветви обработки параметров, полученных по умолчанию и параметров, указанных явно. Например, если есть что-то подобное:

if (prmIsDefault(...))
{
    ...
}
else
{
    ...
}

В данном методе ничего подобного нет, поэтому задача вырождается ко второму варианту.
А для второго варианта универсального подхода просто может и не быть, все зависит от задачи. Сам по себе факт наличия 11 параметров метода наталкивает на мысль от том, что с методом что-то не так. А если учесть, что в этом же классе есть публичный NEW с количеством параметров, превышающем десяток (по крайней мере в DAX2009 это так), то возникает вопрос все ли в порядке с самим классом.
Например (не претендую на истину в последней инстанции, это только мое личное мнение):

• Если решили делать рефакторинг, то вообще тест самого метода не нужен - покрываем тестами свои новшества. Правда тут возникает вопрос именно для этого класса - вдруг решили изменить NEW, то каким образом тестировать как это повлияет на весь класс в целом.
• Если нужно добавить новый параметр (хотя куда уж больше), то тестируем как будет работать метод когда новый параметр передаем, а когда не передаем. Возможно, что после просмотра покрытия, что-то добавим.
• Если нужна только "зеленая стрелка", то тут уже простор для фантазии огромный.

С чисто технической точки зрения тут можно определить только подход для ответа на вопрос

Цитата:

сколько тестирующих методов должно быть

В параметрах модуля тестирования можно задать как действовать при ошибке утверждений в одном тестирующем метод: продолжать выполнять другие методы или прервать тестирование. Для нескольких утверждений в одном методе, метод прерывается если хотя бы одно из утверждений ложно.
Соответственно:

• Если считаем, что метод не работает, если хотя бы одно из утверждений не выполняется, тогда все сочетания тестируем в одном методе.
• Если считаем, что некоторые сочетания параметров редкие и нужно проверять их отдельно, то такие сочетания выделяем в отдельный метод.

Опять же, после анализа покрытия вполне возможно, что подход изменим.
Вообще, unit тесты совсем не про то, что все работает правильно. Они проверяют работает ли метод (класс в целом) так как считает разработчик при проектировании этого метода/класса. Вполне нормальный вариант, что правильность (а не формальность) выносится уже на уровень функциональных тестов.