Цитата:
Сообщение от
fed
Вообще - немного странно что ты решил здесь этот вопрос задать, а не на каком-нибудь .net/java-форуме.
в java и проще, и сложнее.
в аксапте из-за слоев очень стабильный интерфейс классов (сложно расширяемый. extensions опять же, не к ночи будут помятуны)
из-за стабильного интерфейса в аксапте принято добавлять параметры со значениями по умолчанию как средство изменения поведения.
как правило, в аксапте значение по умолчанию порождает старое поведение.
а какое-либо другое значение порождает совсем другое поведение.
(типичный пример - два последних параметра в примере кода выше)
таким образом, в аксапте параметры со значениями по умолчанию хорошо выявляют входящие экстремальные значения. в других средах, экстремальные значения еще и выявить надо (но после выявления, тестирование ничем не отличается от аксаптовского, тут согласен).
да, согласен, что в конечном итоге сводится к набору тестируемых значений и ожидаемых результатов для каждой комбинации.
Но как записывать эти наборы и ожидаемые результаты, если их под несколько сотен?
Генерировать программно? Но это вроде противоречит самой сути unit-тестирования, где программист явно определяет ожидаемый результат для каждого набора... Ну и так далее.
Цитата:
Сообщение от
fed
На мой взгляд, думать о каком-то юнит-тестировании на внедрениях можно только после того как Микрософт начнет сама поставлять свои юнит-тесты и скрипты.
я тоже так раньше думал.
а теперь вижу, что и в юнит-тестах тоже вполне видны исторические пласты, ощущаются былые непримиримые холивары и попытки реализации разных подходов. а также вижу codeReview и слышу что на них говорят... как будто ходишь туристом по Риму.
отсюда и вопрос.
и именно применительно к аксапте.
и надежда, что может кто-то уже ходил этой тропой и кому-нибудь есть что сказать.
Цитата:
Сообщение от
fed
А в данный момент - разумнее работать по старинке - оттестировать силами консультанта базовые сценарии, а потом поставить в продакшн и смотреть что сломается...
наверное.
это тоже один из подходов к unit-тестированию - не делать его.