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

[mazzy]

Цитата:

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

ну по сути это минимальный набор который покажет - не поломался ли метод.

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

Цитата:

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

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

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

и что за случайные выборки?
да, в ax7 добавили sysTestAnyGenerator... но мы ведь не о нем говорим?
что за случайности в unit-тестировании? чего я не понимаю?

[trud]

Цитата:

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

и что за случайные выборки?
да, в ax7 добавили sysTestAnyGenerator... но мы ведь не о нем говорим?
что за случайности в unit-тестировании? чего я не понимаю?

ну предположим у вас поломали метод - перестали обрабатывать _agreementHeaderExtRecId внутри. но собственно данные выбираются так, что строка у которой agreementHeader = agreementHeaderExtRecId выбирается первой и возвращается вам. получится что как бы тест работает правильно, но при наличии других данных в таблице будет неправильная работа.

вообще немного подумав - что бы я как разработчик решения хотел бы получить от микрософт. наверное все же не 2, а набор тестов которые тестируют каждый параметр и проверяют что одно изменение параметра приводит к отличию в выполнении.
т.е. в данном случае 11 параметров, на каждый параметр по 2 значения
получается тест с 22 вариантами - на каждый вариант должна быть своя цена. плюс скрипт который генерит 22 разных записи в таблице цен
так бы я проверил, что мой код не поломал стандарт

[belugin]

Цитата:

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

А не побухтеть ли нам, уважаемые кроты?

Предположим, есть метод с кучей параметров по умолчанию. (см. скриншот)

Как бы вы написали такой unit test?

Рефакторить, если нельзя рефакторить, оборачивать хелперами.

void testFindDisc_byRelationAgreementHeader_ifAgreementHaderDoesNotMatch_returnsNothing()
{
      ...
      this.assertFalse(this.findByAgreementHeader(relation, dimId, NotExistringAGreementHHeader));
}

Цитата:

Какую стратегию вы считаете правильной для тестирования методов с параметрами по умолчанию? Почему?
Какие статьи/книги/ссылки вы считаете релевантными по данной теме? Почему?

http://xunitpatterns.com/

[mazzy]

Цитата:

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

http://xunitpatterns.com/

прекрасно!
спасибо за ссылку и за книгу.

и все же. а можно поконкретнее?

[Андре]

1. В общем то, как написал fed - unit test-ирование полезно, когда значительная (по моим оценкам не менее 40% кода) часть кода покрыта unit тестами. Если тесты на стандартный код не появились - это все, вроде как, имеет мало смысла.

2. Что гораздо хуже, большая часть Ax кода написана так, что на нее невозможно написать unit тесты. Чтобы код было удобно тестировать, все с чем он работает тем или иным образом должно передаваться в класс (или метод) - см. прием/паттерн Dependency Injection. В Ax этот принцип нарушается везде

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

[mazzy]

Цитата:

Сообщение от Андре

Если тесты на стандартный код не появились

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

Цитата:

Сообщение от Андре

Что гораздо хуже, большая часть Ax кода написана так, что на нее невозможно написать unit тесты. ...mock для базы данных и передать его в этот метод

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

т.е. mock база есть. и она не пустая.

я так понимаю, что в мс есть специальные атрибуты, которые заставляют тестовую среду перед запуском тестов установить демобазу, компанию и страну.

[Андре]

Цитата:

которые заставляют тестовую среду перед запуском тестов установить демобазу, компанию и страну

Тогда это интеграционные тесты, а не unit тестирование.

Но проблема же не только в БД. Может с тех пор как я смотрел в Ax что-то изменилось, но создание объектов в конструкторе объекта, как и в его методах раньше встречалось повсеместно и было правилом, а не исключением.

[mazzy]

Цитата:

Сообщение от Андре

Но проблема же не только в БД. ...создание объектов в конструкторе объекта, как и в его методах раньше встречалось повсеместно и было правилом, а не исключением.

да, и сейчас повсеместно.
да, и сейчас добавляются параметры со значениями по умолчанию.
да, и сейчас возможность рефакторинга очень и очень ограничена. даже в мс.
и прочие отличия аксапты от того же c#, java, php.

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

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

[Андре]

Цитата:

поэтому ожидаю, что высказывающиеся расскажут не только о приемах правильного unit-тестирования, но и о том какие цели удовлетворяются при том или ином приеме

Вообще, целью unit тестирования для меня является минимальная гарантия того, что я смогу сегодня ночью спокойно спать и меня не разбудят со словами, что что-то отвалилось.

С этой же задачей хорошо справляется строгая статическая типизация, которую по эффективности я бы поставил даже на первое место. Именно она - та причина, по которой в production я предпочту использовать f# или haskell, а не clojure. Именно она является причиной того, что я буду пропагандировать TypeScript и настаивать на его использовании вместо JS.

Если твои цели совпадают с моими, может просто рассмотреть другие способы проверки работатоспособности продукта, нежели unit тесты, которые не очень вписываются в концепцию продукта ?

[mazzy]

Цитата:

Сообщение от Андре

Вообще, целью unit тестирования для меня является минимальная гарантия того, что я смогу сегодня ночью спокойно спать и меня не разбудят со словами, что что-то отвалилось.

другими словами, контроль регрессии.
пусть так.

какая стратегия в имеющихся условиях в имеющейся аксапте с имеющимся инструментом SysTest* является правильной? И почему?

для определенности, давай сосредоточимся на методах с параметрами по умолчанию на примере PriceDisc::findDisc )))

Цитата:

Сообщение от Андре

Если твои цели совпадают с моими, может просто рассмотреть другие способы проверки работатоспособности продукта, нежели unit тесты, которые не очень вписываются в концепцию продукта ?

Да, это один из вариантов развития.

но что хотелось бы:
1. прикидываем правильную стратегию контроля регрессии для аксапты и для того, что в ней называется юнит-тестированием
2. прикидываем правильную стратегию контроля регрессии для другого способа.
3. сравниваем трудоемкость
4. ...
5. PROFIT

но для этого нужно хотя бы как-то определится с правильной стратегией и понять какой ценой эта правильность обеспечивается в Аксапте.

[Андре]

Цитата:

другими словами, контроль регрессии.
пусть так.

какая стратегия в имеющихся условиях в имеющейся аксапте с имеющимся инструментом SysTest* является правильной? И почему?

Ну, я свое мнение озвучил Написание unit test-а в Ax не прибавляет мне никакой уверенности в том, что последние изменения в коде ничего не поломали. А значит (с моей точки зрения) являются тратой времени.

Может у кого-то был противоположный опыт ?

[trud]

Цитата:

Сообщение от Андре

Написание unit test-а в Ax не прибавляет мне никакой уверенности в том, что последние изменения в коде ничего не поломали.

ну вот я полностью согласен. т.е. по хорошему тестировать надо не методы, а процессы - т.е. в нашем случае - при создании строки заказа подставилась правильная цена.
в ах7 есть определенные шаги в этом направлении - создали форм адаптеры - классы для форм которые один в один отражаются на контролы формы.
но я вот не очень честно говоря представляю как вообще должен выглядеть тест на создание и разноску заказа, что проверять, каким образом генерить данные и т.д.

[Андре]

Цитата:

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

Теоритически есть продукты, которые автоматически щелкают по полям форм: заполняют данные, разносят заказ и потом считывают из полей полученный результат. Если уже есть база данных для тестирования - можно посмотреть в эту сторону.

Я так не делал - слишком ленив Во первых надо тратить кучу времени на поддержку всех тестов в актуальном состоянии. Во вторых БД должна содержать набор данных для покрытия всех основных сценариев, а значит надо следить и за ее актуальностью.

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

Еще раз - такой способ подойдет не всем и не всегда

[trud]

Цитата:

Сообщение от Андре

Теоритически есть продукты, которые автоматически щелкают по полям форм: заполняют данные, разносят заказ и потом считывают из полей полученный результат.

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

[Logger]

Цитата:

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

непонятно что собственно делать дальше, т.е. как проверить к примеру "правильность" разноски. учитывая что часть данных вообще зависит от системной даты

Написать метод проверяльщик.
Или может та система которую там демили уже так умеет ?
Проблему с датой не вижу. Ее тоже можно выставить, даже из интерфейса.
Или тогда надо ее как параметр вводить в метод проверки.

[mazzy]

Цитата:

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

непонятно что собственно делать дальше, т.е. как проверить к примеру "правильность" разноски. учитывая что часть данных вообще зависит от системной даты

насколько я понимаю, проверку сводят к тому же инструменту SysTesCase.
атрибутами устанавливают область FunctionTest.
такие классы проверяются в рамках отдельного шага после успешного прохождения CheckInTest...
есть и UnitTest, есть и IntegrationTest, есть еще несколько типов, которые влияют на checkin, последовательность, периодичность, критичность проверки.

в общем, задают параметры работы тестовой среды атрибутами.
но в конечном итоге все равно нужно написать некий класс, унаследованный от SysTestCase...

Отсюда собственно и тема этой ветки )))

[ALES]

Цитата:

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

непонятно что собственно делать дальше, т.е. как проверить к примеру "правильность" разноски. учитывая что часть данных вообще зависит от системной даты

Денис, ты не можешь не знать решения, где сразу непосредственно "правильная" разноска в БД записывается

[ALES]

Цитата:

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

..но в конечном итоге все равно нужно написать некий класс..

А смысл? Даже если отбросить "дефолтный" параметр с recid=0 и т.д., "механически верный" поиск по inventDimId предполагает обширные "тайные знания" по применяемым "схемам" учета, логике формирования строк в соотв. таблицах, кастомизациям всего этого "вокруг".. В общем виде от написанного класса получаем подтверждение "найдем строку скидки если код аналитики есть в поле таблички" вместо условно ожидаемого "найдем скидку, как для холодильника зеленого цвета так и для трех вагонов песка, а для восьми вагонов она еще больше" . Еще раз, Сергей, что ты хочешь от юнит теста этого метода? "return "зеленый квадратик"" или что-то другое?

[trud]

А вот на скриншоте макрос #voucher чему равен? т.е. предполагается что в результате теста один и тот же ваучер получается?

[mazzy]

Цитата:

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

А смысл? Даже если отбросить "дефолтный" параметр с recid=0 и т.д., "механически верный" поиск по inventDimId предполагает обширные "тайные знания" по применяемым "схемам" учета, логике формирования строк в соотв. таблицах, кастомизациям всего этого "вокруг"..

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

Цитата:

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

Еще раз, Сергей, что ты хочешь от юнит теста этого метода? "return "зеленый квадратик"" или что-то другое?

как всегда, захватить мир
понять. и простить. )))

если так проще для рассуждений, то наличие unit-теста является обязательным при checkin'е кода в мс.
поэтому формально - именно "зеленый квадратик".

но я смотрю на уже существующие тесты. там чего только нет.
помню себя и как я сам надеялся "вот у вендора то"... )))

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

теперь хотелось бы понять какие результаты и усилия народ считает достаточным.
и как этих результатов добиться с минимальными трудозатратами.

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

Цитата:

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

А вот на скриншоте макрос #voucher чему равен? т.е. предполагается что в результате теста один и тот же ваучер получается?

да. нумераторы тоже настраиваются в рамках setup-метода. каждый запуск test-метода происходит в одинаковом окружении.