gifts2017

Обработка для юнит-тестирования

Опубликовал Игорь Николаев (CyberRich) в раздел Программирование - Инструментарий

Обработка предназначена для автоматизированного выполнения юнит-тестов при написании кода методом «Разработка через тестирование» («TDD»), применяющимся как самостоятельно, так и, в частности, в методике экстремального программирования.

Обработка позволяет выполнить все предварительно написанные тесты одним нажатием кнопки и узнать результат их прохождения.

Обработка работает следующим образом:

Вы пишете тест в виде отдельной функции, которая передает тестируемому куску кода заранее определенные входные данные и сравнивает рассчитанный результат с результатом, заранее определенным программистом.  Тест возвращает структуру из двух переменных: булево «ТестПрошел» - флаг успешного прохождения теста и строка «СообщениеОбОшибке» - сообщение, которое нужно показать пользователю в случае неудачного выполнения теста. Тесты можно размещать в общих модулях, можно и в модулях объектов.

В табличное поле на форме обработки заносите перечень тестов. Каждая строка перечня содержит название теста и имя метода – функции, в которой выполняется тест. Перечень можно сохранить в файл на диске нажатием кнопки «Сохранить тесты». Если тест расположен в модуле объекта, помните, что для его вызова нужно сначала создать объект. Таким образом, имя метода будет выглядеть так: Документы.РасчетСуммы.СоздатьДокумент().ТестРассчетаОбратнойРеализации()

По нажатию кнопки «Выполнить тесты», обработка по очереди вызывает все тесты из перечня. Если все они завершились удачно, поле «Результат» окрасится в зеленый цвет («Зеленая полоска»). Если же какой-либо тест вернул отрицательный результат, или выпал с ошибкой, обработка сообщит об этом, выведет переданные несработавшими тестами сообщения, а поле «Результат» окрасится в красный цвет («Красная полоска»).

Пример теста:

Функция ТестРассчетаОбратнойРеализации() Экспорт
                Ответ=Новый Структура;                 
                Ответ.Вставить("ТестПрошел",Ложь);
                Ответ.Вставить("СообщениеОбОшибке","");
               
                Попытка                                
                               Об=Документы.РасчетСумм.СоздатьДокумент();
                               Стр=Новый Структура;               // Готовим входные параметры для тестируемой процедуры
                               Стр.Вставить("Сумма",0);        
                               Стр.Вставить("РыночнаяЦена",100);
                               Стр.Вставить("СтоимостьВозможнойПродажи",70);
                               Стр.Вставить("Количество",7);
                               Об.РассчитатьОбратнуюРеализацию(Стр);    // Вызываем саму процедуру, передавая ей тестовые данные
                               Если Стр.Сумма<>455 Тогда               // Если рассчитанное процедурой значение не совпадает
                                                                                   // с посчитанным нами - тест не прошел
                                               Ответ.СообщениеОбОшибке="Неправильная сумма";
                               Иначе
                                               Ответ.ТестПрошел=Истина;
                               КонецЕсли;
                Исключение
                               Ответ.ТестПрошел=Ложь;
                               Ответ.СообщениеОбОшибке="Ошибка при выполнении теста";
                КонецПопытки;
               
                Возврат Ответ;
КонецФункции

Все вопросы, кроме «А зачем оно нада?», задавайте в комментариях. Для ответа на вопрос «А зачем оно нада?» гуглите «разработка через тестирование».

Скачать файлы

Наименование Файл Версия Размер Кол. Скачив.
Автоматическое тестирование (управляемая форма)
.epf 13,76Kb
15.01.16
0
.epf 13,76Kb 0 Скачать
Автоматическое тестирование (обычная форма)
.epf 8,57Kb
15.01.16
0
.epf 8,57Kb 0 Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Messenger Unchained (Messenger Unchained) 15.01.16 18:59
Все вопросы, кроме «А зачем оно нада?», задавайте в комментариях. Для ответа на вопрос «А зачем оно нада?» гуглите «разработка через тестирование».


А зачем оно нада? Ты внезапно обнаружил у xUnitFor1C фатальный недостаток?
awa; ojiojiowka; tormozit; amon_ra; yurii_host; ardn; +6 Ответить
2. Юрий Былинкин (ardn) 15.01.16 20:04
Дело конечно хорошее, но...
Что есть в вашей обработке, чего нет в xUnitFor1C?
3. Игорь Николаев (CyberRich) 16.01.16 20:35
(2) ardn, сказать по правде, писал обработку для лучшего понимания сути процесса "изнутри". Вдруг кому еще пригодится в этих же целях.
4. Allexey (alex_4x) 25.01.16 09:57
Наверняка это очень полезная и ценная обработка. Вот бы еще инструкцию как сам метод разработки через тестирование применять в 1С.
Я мало что в разработке через тестирование понимаю, и у меня такое ощущение (скорее всего ошибочное) что эту методологию можно применять только в очень простых подзадачах. Ну условно при разработке веб страницы - там подзадачи просты и мало связаны, имеют малую степень зависимости друг от друга, и такая методика там применима. В то же время, если все задачи переплетены - то от TDD больше проблем, чем пользы. В любом случае было бы очень интересно почитать как автор предлагает разрабатывать через тестирование на 1С. Конечно лучше с примерами. Это было бы гораздо более ценно, чем сама обработка.
5. Игорь Николаев (CyberRich) 29.01.16 11:48
(4) alex_4x, именно в очень простых подзадачах! С первого взгляда на методику мне тоже трудно было понять отличия приемочных тестов от модульных. Так вот: приемочные тесты служат для тестирования решения вцелом. А модульные тесты используются именно для того, чтобы ГАРАНТИРОВАТЬ правильную работу какого-либо очень простого механизма (например, одной функции) в составе программного решения. Это очень важное условие для дальнейшего использования такого метода, как рефакторинг: пересмотра уже написанного и работающего кода с целью его упрощения и оптимизации. Если тесты охватывают всю область входных данных механизма, можно сразу же, запустив тест, проверить, по прежнему ли механизм работает как должно. Поначалу очень неуютно нарушать правило "работает-не трогай", но попробовав такой метод, я для себя решил однозначно: оно того стоит. Для сложных механизмов, где задачи переплетены, методика тем более приносит неоценимую пользу: в любой момент программист уверен, что конкретные отдельные процедуры и функции работают правильно. Главное - спроектировать систему как совокупность механизмов, которые представляются для остальных механизмов атомарным, законченными "черными ящиками". А при работой над новым механизмом по несработавшим тестам сразу видишь, где взаимосвязи нарушаются, обрабатываешь эти моменты и опять получаешь стабильную, контролируемую тестами систему. Как то так. Чуть позже попробую кратенько описать использования юнит-тестов лично мной.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа