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

[fed]

Вообще - немного странно что ты решил здесь этот вопрос задать, а не на каком-нибудь .net/java-форуме.
Во первых, по моим наблюдениям, на реальных внедрениях бюджет на тестирование весьма ограничен и ни на какие юнит-тесты его просто не хватит.
Во вторых - окидывая глазами тот код на X++ который я за 16 лет написал: Наверное я могу припомнить два-три случая, когда логика в моей разработке была достаточно сложной чтобы в принципе оправдать какие-то затраты на юнит-тестирование. Но все равно - при моей занятности проще было собрать молодых консов и за 10-15 минут объяснить им про возможные комбинации параметров и подводные грабли. В то же время кодирование юнит-тестов потребовало бы от меня эдак часика 3-4 работы.
Наконец - как ты сам знаешь, главный риск от разработки на внедрениях - это риск сломать какой-то микрософтовский механизм (причем скорее всего тот, о котором ты даже и не знаешь). А тут никакой юнит-тест не поможет. Как я могу протестировать что-то, о функционировании чего я вообще не догадываюсь ?
На мой взгляд, думать о каком-то юнит-тестировании на внедрениях можно только после того как Микрософт начнет сама поставлять свои юнит-тесты и скрипты.
А в данный момент - разумнее работать по старинке - оттестировать силами консультанта базовые сценарии, а потом поставить в продакшн и смотреть что сломается...

[mazzy]

Цитата:

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

Вообще - немного странно что ты решил здесь этот вопрос задать, а не на каком-нибудь .net/java-форуме.

в java и проще, и сложнее.

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

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

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

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

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

Цитата:

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

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

я тоже так раньше думал.

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

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

Цитата:

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

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

наверное.
это тоже один из подходов к unit-тестированию - не делать его.