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

[Андре]

Цитата:

кроме того, что это фишка аксапты, если я правильно понимаю.

Дефолтные параметры ? Да они даже в C# есть

PHP код:

public void ExampleMethod(int required, string optionalstr = "default string",
            int optionalint = 10) 


Цитата:

А вот тут похоже и есть корень.
В аксапте чаще наоборот. И об этом писал fed выше.

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

Нет, мне кажется мы по разному понимаем unit тестирование. И мне кажется что мое понимание ближе к "каноническому"

Тест который тестирует твой код, и тест который тестирует стандартный функционал, который использует твой код - это разные тесты.

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

Каждый unit тест не проверяет весь мир вокруг. Он проверяет изолированный кусочек кода.

Код настолько легко будет тестировать с помощью unit-тестирования, насколько легко из него можно будет вычленять вот эти независимые кусочки. Код, который ты привел, с точки зрения тестирования - жесть. Его невозможно рассматривать независимо от всего мира вокруг. Он работает напрямую с таблицами БД, он обращается к статическим методам других таблиц. В него встроена (а не передается снаружи) обвязка для кеширования уже посчитанных значений. Это означает, что я не могу передать для нее mock. А надо. Так как это кеширование должно проверяться отдельно от этого метода, в отдельном unit тесте. А здесь я хочу тестировать логику метода.

У кода есть разные характиристики. Например, его производительность (насколько быстро он работает), читаемость (насколько легко читать код), поддерживаемость (насолько легко добавлять в код новые возможности). А еще есть такая характеристика, как тестируемость. Насколько легко код тестировать. Как и во всех остальных случаях, тестируемость кода не возникает сама по себе. Для этого надо прилагать дополнительные усилия. Иногда тестируемость может вхождить в конфликт с другими требованиями к коду. Например, с производительностью или даже читаемостью.

Очевидно, что у разработчиков Ax тестируемость кода не была приоритетом номер один.Скорее всего вообще, она не была в приоритетах. Я не говорю, что это плохо для продукта в общем. Наверное, расставив приоритеты таким образом они что-то и выиграли. Но, на мой взгляд, этот выбор привел к тому, что Ax и unit тестирование не рассматривают вместе.

[mazzy]

Цитата:

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

Дефолтные параметры ? Да они даже в C# есть

они там появились совсем недавно.
в принципе народ пока только осваивает их.
раньше в C# нужно было делать кучу overload методов.
для каждого метода свой unit-тест и вася-кот. все было логично.

дефолтные параметры есть в basic, php.
но в этих системах не было слоев, из-за которых интерфейс был очень стабильным.

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

Цитата:

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

Нет, мне кажется мы по разному понимаем unit тестирование. И мне кажется что мое понимание ближе к "каноническому"

Тест который тестирует твой код, и тест который тестирует стандартный функционал, который использует твой код - это разные тесты.

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

Каждый unit тест не проверяет весь мир вокруг. Он проверяет изолированный кусочек кода.

возможно. надо подумать.

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

[Ruff]

Цитата:

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

раньше в C# нужно было делать кучу overload методов.

Я почти уверен, что в Аксапте именно так и транслируются методы со значениями по умолчанию - в кучу overload методов. Если только в семерке в Х++ не добавили "именованные" параметры, как в шарпе, то получаем не 2^8 комбинаций дефолтности, а всего лишь 9.
Таким образом, можно свести дальнейший поиск стратегии к умозрительному варианту, что у нас в классе есть 9 методов findDisc:

boolean findDisc(PriceType             _relation, 
                  InventDimId           _inventDimId,
                  TableGroupAll         _itemCode, 
                  ItemId                _itemRel,
                  TableGroupAll         _accountCode,
                  CustVendAC            _accountRel,
                  UnitOfMeasureSymbol   _unitID,
                  Qty                   _quantityAmoun,
                  CurrencyCode          _currency,
                  AgreementHeaderExtRecId_RU _agreementHeaderExtRecId,
                  CustVendAC                 _agreementPartnerCode,
                  LogisticsPostalAddressRecId _deliveryPostalAddress)
{      
//  основной код 
}
// здесь еще 7 методов
// ...
boolean findDisc(PriceType _relation, InventDimId _inventDimId)  
{      
  return findDisc(_relation, _inventDim, 0,'',0,'','',0,CompanyInfo::standardCurrency(),0,'',0);     
}

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

Цитата:

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

для каждого метода свой unit-тест и вася-кот. все было логично.