Цитата:
Сообщение от
ALES
А смысл? Даже если отбросить "дефолтный" параметр с recid=0 и т.д., "механически верный" поиск по inventDimId предполагает обширные "тайные знания" по применяемым "схемам" учета, логике формирования строк в соотв. таблицах, кастомизациям всего этого "вокруг"..
вообще говоря, unit-тестирование предполагает, что все запуски выполняются в одном и том же окружении. поэтому при правильном подходе "вокруг" ничего меняться не должно.
Цитата:
Сообщение от
ALES
Еще раз, Сергей, что ты хочешь от юнит теста этого метода? "return "зеленый квадратик"" или что-то другое?
как всегда, захватить мир
понять. и простить. )))
если так проще для рассуждений, то наличие unit-теста является обязательным при checkin'е кода в мс.
поэтому формально - именно "зеленый квадратик".
но я смотрю на уже существующие тесты. там чего только нет.
помню себя и как я сам надеялся "вот у вендора то"... )))
вот я и хочу понять как народ делает, что народ считает правильным.
что народ хочет от юнит-тестирования и что удается получить на практике.
да, я услышал, что в этой ветке говорилось только о регрессии.
и таки да, наверное вряд ли стоит ожидать чего-то другого от тестирования в коде.
таки да - юнит-тесты это некие сторожевые собачки, расставленные по периметру кода.
теперь хотелось бы понять какие результаты и усилия народ считает достаточным.
и как этих результатов добиться с минимальными трудозатратами.
в частности, в случае, когда комбинаций входящих параметров может быть несколько сотен.
Цитата:
Сообщение от
trud
А вот на скриншоте макрос #voucher чему равен? т.е. предполагается что в результате теста один и тот же ваучер получается?
да. нумераторы тоже настраиваются в рамках setup-метода. каждый запуск test-метода происходит в одинаковом окружении.