Обработка позволяет выполнить все предварительно написанные тесты одним нажатием кнопки и узнать результат их прохождения.
Обработка работает следующим образом:
Вы пишете тест в виде отдельной функции, которая передает тестируемому куску кода заранее определенные входные данные и сравнивает рассчитанный результат с результатом, заранее определенным программистом. Тест возвращает структуру из двух переменных: булево «ТестПрошел» — флаг успешного прохождения теста и строка «СообщениеОбОшибке» — сообщение, которое нужно показать пользователю в случае неудачного выполнения теста. Тесты можно размещать в общих модулях, можно и в модулях объектов.
В табличное поле на форме обработки заносите перечень тестов. Каждая строка перечня содержит название теста и имя метода – функции, в которой выполняется тест. Перечень можно сохранить в файл на диске нажатием кнопки «Сохранить тесты». Если тест расположен в модуле объекта, помните, что для его вызова нужно сначала создать объект. Таким образом, имя метода будет выглядеть так: Документы.РасчетСуммы.СоздатьДокумент().ТестРассчетаОбратнойРеализации()
По нажатию кнопки «Выполнить тесты», обработка по очереди вызывает все тесты из перечня. Если все они завершились удачно, поле «Результат» окрасится в зеленый цвет («Зеленая полоска»). Если же какой-либо тест вернул отрицательный результат, или выпал с ошибкой, обработка сообщит об этом, выведет переданные несработавшими тестами сообщения, а поле «Результат» окрасится в красный цвет («Красная полоска»).
Пример теста:
Функция ТестРассчетаОбратнойРеализации() Экспорт
Ответ=Новый Структура;
Ответ.Вставить("ТестПрошел",Ложь);
Ответ.Вставить("СообщениеОбОшибке","");
Попытка
Об=Документы.РасчетСумм.СоздатьДокумент();
Стр=Новый Структура; // Готовим входные параметры для тестируемой процедуры
Стр.Вставить("Сумма",0);
Стр.Вставить("РыночнаяЦена",100);
Стр.Вставить("СтоимостьВозможнойПродажи",70);
Стр.Вставить("Количество",7);
Об.РассчитатьОбратнуюРеализацию(Стр); // Вызываем саму процедуру, передавая ей тестовые данные
Если Стр.Сумма<>455 Тогда // Если рассчитанное процедурой значение не совпадает
// с посчитанным нами - тест не прошел
Ответ.СообщениеОбОшибке="Неправильная сумма";
Иначе
Ответ.ТестПрошел=Истина;
КонецЕсли;
Исключение
Ответ.ТестПрошел=Ложь;
Ответ.СообщениеОбОшибке="Ошибка при выполнении теста";
КонецПопытки;
Возврат Ответ;
КонецФункции
Все вопросы, кроме «А зачем оно нада?», задавайте в комментариях. Для ответа на вопрос «А зачем оно нада?» гуглите «разработка через тестирование».
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
А зачем оно нада? Ты внезапно обнаружил у фатальный недостаток?
Дело конечно хорошее, но…
Что есть в вашей обработке, чего нет в xUnitFor1C?
(2) ardn, сказать по правде, писал обработку для лучшего понимания сути процесса «изнутри». Вдруг кому еще пригодится в этих же целях.
Наверняка это очень полезная и ценная обработка. Вот бы еще инструкцию как сам метод разработки через тестирование применять в 1С.
Я мало что в разработке через тестирование понимаю, и у меня такое ощущение (скорее всего ошибочное) что эту методологию можно применять только в очень простых подзадачах. Ну условно при разработке веб страницы — там подзадачи просты и мало связаны, имеют малую степень зависимости друг от друга, и такая методика там применима. В то же время, если все задачи переплетены — то от TDD больше проблем, чем пользы. В любом случае было бы очень интересно почитать как автор предлагает разрабатывать через тестирование на 1С. Конечно лучше с примерами. Это было бы гораздо более ценно, чем сама обработка.
(4) alex_4x, именно в очень простых подзадачах! С первого взгляда на методику мне тоже трудно было понять отличия приемочных тестов от модульных. Так вот: приемочные тесты служат для тестирования решения вцелом. А модульные тесты используются именно для того, чтобы ГАРАНТИРОВАТЬ правильную работу какого-либо очень простого механизма (например, одной функции) в составе программного решения. Это очень важное условие для дальнейшего использования такого метода, как рефакторинг: пересмотра уже написанного и работающего кода с целью его упрощения и оптимизации. Если тесты охватывают всю область входных данных механизма, можно сразу же, запустив тест, проверить, по прежнему ли механизм работает как должно. Поначалу очень неуютно нарушать правило «работает-не трогай», но попробовав такой метод, я для себя решил однозначно: оно того стоит. Для сложных механизмов, где задачи переплетены, методика тем более приносит неоценимую пользу: в любой момент программист уверен, что конкретные отдельные процедуры и функции работают правильно. Главное — спроектировать систему как совокупность механизмов, которые представляются для остальных механизмов атомарным, законченными «черными ящиками». А при работой над новым механизмом по несработавшим тестам сразу видишь, где взаимосвязи нарушаются, обрабатываешь эти моменты и опять получаешь стабильную, контролируемую тестами систему. Как то так. Чуть позже попробую кратенько описать использования юнит-тестов лично мной.