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

[trud]

Цитата:

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

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

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

[Logger]

Цитата:

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

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

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

[trud]

Цитата:

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

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

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

Цитата:

CU12 Known Issue – Incorrect Posting amounts – Shipment Packing slip posting
Known scenarios
The released product is associated with an item model group where Post physical inventory to ledger = True or Post to Deferred Revenue Account on sales delivery = True, and
Sales order line lot ID is split based on output orders and grouped in the same shipment, and
Sales packing slip is posted from Inventory management>Common>Shipments.

[mazzy]

Цитата:

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

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

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

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

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

[ALES]

Цитата:

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

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

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

[ALES]

Цитата:

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

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

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