Юнит-тестирование #701613

Добрый день. Занимался ли кто юнит-тестированием? Я написал конфигурацию для юнит-тестирования (с видеоинструкцией): . Интересно ваше мнение, насколько тема (и конфа) полезна / бесполезна / востребована - в общем, критика.

Выложил в неудачном месте

Что есть юнит тестирование?

Будет бесплатное скачивание - может, посмотрю.

Тестирование модулей. Зачем все эти английские слова.

там никогда не будет бесплатно...

Круто. Можно менеджеров заменить на эту программу.

ишЪ, как повалило: надысь на хабре , нынча на мисте… эдак годков через 5 1С сама тестирорование в платформу встроит

Конфа бесплатная.

дак есть же уж тестировалки всякие, ижтиси и прочая ересь

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

Выглядит круто. Но объясните мне, плиз,  где эти штуки в жизни нужны, если я свое типовое решение не изобретаю, а чужие допиливаю

вот парни тоже юниттест пилят: а так штука полезная, конечно, например когда надо документы под баланс подогнать )))

Так есть же в 8.3 уже. Али ещё допиливают?

То, что предлагает автор - это не юнит-тестирование. Юнит-тестирование (модульное тестирование) - это тестирование отдельных программных подсистем, без привязки к интерфейсу и взаимодействия их с тдугими подсистемами. Например, код, который создает документ, проводит его и проверяет что движения по регистрам совпадают с табличной частью - можно с натяжкой назвать юнит-тестом. С натяжкой- потому что обычно модуль проведения использует несколько "подсистем", кждую из которых, по идее, нужно тестировать отдельно.

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

, Согласен. У меня по сути сценарное тестирование. Спасибо за поправку.

Юнит тесты - это то, чего в 1С очень сильно не хватает. Автор молодец.

Я вижу два применения: 1) В регрессионных тестах (проверка, что после очередных изменений конфы не развалились сценарии использования, для которых написаны тесты) 2) При нагрузочном тестировании (для полноценной имитации действий пользователя), а не только "синтетики", выполняемой на сервере.

А вы используете этот инструмент на живих проектах? если используете - то можете рассказать поподробнее об этом?

А есть возможность сохранять начальное состояние базы и после запуска теста возвращать бзу в первоначальное состояние. Т.е. напримемр, если тест создает какие-то объекты, то как потом "откатить" состояние БД на то, которое было до запуска теста?

Спасибо, но автору - мимо. Попробуйте после обновления потестить этой штукой чето на основе УПП - пары суток не хватит. Поэтому просто перепроводим документы, открываем отчеты и формы созданных документов и справочников, смотрим, что ничего не отвалилось и молимся Гейтсу. Главное, чтобы перепроводилось, исправленную форму всегда можно внешней обработкой выслать.

Код сценарного тестирования этого проекта использовал в тест-центре для имитации 50 пользователей, оформляющих продажи. Хороший вопрос, надо добавить в конфу операции удаления созданного. Это реализуемо: две операции удаления, которые по полю номера / кода для форм документа / справочника будут их удалять.

там же может быть не только удаление, но и например изменение данных. Представьте, что у меня есть обработка, которую я хочу протестирвать на всех релизах типовой БП 2.0

НачатьТранзакцию ОтменитьТранзакцию

стресс-тесты - это гораздо проще. Вы их раз написали, пару раз прогнали и ок. Если вы попытаетесь написать сценарные тесты на какую-нибудь БП, то после каждого релиза затраты на их починку будут превышать затраты на ручное тестирование, ИМХО.

смешная шутка

Интересно, посмотрим .

Это ты так думаешь. У инфостарта другое мнение.

+1 пора уже на github выкладывать.