Многие программисты знают это "Папино" состояние. Когда программа стала настолько сложной, что внесение минимальных дополнений требует внимательного кодирования в пятнадцати местах, а ошибку приходится выискивать по полдня. Некоторые программисты даже настолько сжились с таким состоянием, что принимают фразу "Работает - не трогай" за аксиому. Однако следование этому принципу неизбежно приводит к еще большему нарастанию сложности программы, и еще большей невозможности изменить хоть что-то.

На заре своей работы программистом я частенько допускал глупые ошибки. Эти ошибки редко приводили к фатальным последствиям, но пользователи были очень недовольны. Более того, и сейчас я допускаю все те же глупые ошибки. А мое нынешнее профессиональное умение заключается только в том, что я умею с умным видом объяснить, что так и было задумано, и за то время, пока я это объясняю, быстренько все поправить. Однако и тогда, и сейчас, после таких ошибок меня вызывал руководитель и строгим голосом требовал, чтобы я после любого изменения проверял абсолютно все. И уж по крайней мере, чтобы после внесения изменений я приходил бы к 8-ми утра. Я вежливо кивал, через неделю все забывалось, а через пару месяцев (или через год) все повторялось.

Однако недавно ситуация принципиально поменялась. На одном из форумов hare.ru (хареру умер, ссылка битая) кто-то задал вопрос, не применяет ли кто под 1С "Экстремальное программирование". И даже дал ссылку на русскоязычный сайт, посвященный XP (Тогда это был www.xprogramming.ru, сейчас там какая-то коммерция). Я, почитал, подумал, и для себя решил, что пожалуй, мне нравятся идеи, заложенные в основу XP. Разумеется, среда V7 накладывает определенные ограничения, и полностью и досконально следовать предложенной технике, программируя под 1С, довольно трудно. Тем не менее, проблемы, обрисованные в первых двух абзацах, имеют определенное решение.

Я не буду в этой статье пропагандировать XP. Пусть интересующиеся люди сходят на Википедию погуляют по ссылкам, и сами для себя все решат. Хочу только сказать, что идея автоматического тестирования - пожалуй единственная, которая принимается абсолютно всеми, даже ярыми противниками XP. И это понятно, ибо автоматическое тестирование самоценно и позволяет получить немедленную отдачу, вне зависимости от того, применяете вы другие практики XP или нет.

Что такое просто тестирование - довольно понятно на интуитивном уровне. Тестирование - это проверка того, насколько программа соответствует нашим ожиданиям от нее.
Это кажется простым. Тем не менее, этой мыслью нужно глубоко проникнуться, поскольку не поняв, что такое тестирование - мы не сможем перейти к тестированию автоматическому.

Итак, в тестировании участвует два объекта: а) программа, б) наши ожидания от программы. Поговорим немного об ожиданиях. Что это?
На примере: мы хотим, чтобы приходная накладная при проведении создавала две проводки: Дт 41.1 - Кт 60.1 на сумму накладной без НДС; и вторую: Дт 19.3 - Кт 60.1 на сумму НДС.
Описанный здесь тест состоит из трех частей: мы указали на объект тестирования (приходная накладная), мы указали проверяемое действие (формирование проводок при проведении), и наконец, мы указали ожидаемый результат указанного действия (конкретный набор проводок).
Сами по себе ожидания - не имеют смысла. Чтобы они заговорили - необходим тестируемый объект и тестируемое действие. Такой набор из трех компонентов и называется тестом. Тесты лучше хранить отдельно от самой программы. Что бы ни случилось с программой - тесты являют собой самостоятельную ценность.

Теперь понятно, что сам процесс тестирования оказывается ни чем иным, как простейшей операцией сравнивания. Мы берем тестируемый объект, применяем к нему тестируемое действие, получаем некий результат. Этот результат мы сравниваем с ожиданием. Если результат идентичен ожиданию - значит программа работает так, как ожидается. Если есть расхождения - где-то спряталась ошибка.

Скептик может сказать, что такие простые вещи проверяются глазами. Однако когда таких "простых вещей" становится много, то памяти и глаз уже не хватает. Когда памяти не хватает - приходится записывать :). Для этого нам нужна тестовая БД, где можно создать пример приходной накладной. Еще нам нужно место, куда можно записать, что эта приходная накладная создает именно такие проводки, и никаких больше. В это же место мы сможем записывать другие такие же тесты.

Теперь сделать переход от простого тестирования к автоматического - довольно просто. Чтобы наше тестирование стало автоматическим - нам нужна программа со следующими свойствами. Программа должна уметь применять к тестируемым объектам тестируемые методы. Программа должна уметь сравнивать результат выполнения метода с ожиданием, и в случае расхождений - максимально подробно описывать эти расхождения. Ну и наконец, эта программа должна уметь обрабатывать сразу много тестов в одном пакете.

Такой подход имеет свои плюсы. Основной довод противников автоматического тестирования - "Что произойдет, если ошибка возникнет в программе тестирования?". На первый взгляд - очень веский аргумент. Однако довольно трудно ошибиться в написании программы сравнения одного с другим. Все остальные части программы тестировщика - некритичны к ошибкам.

Однако, есть и минусы. Во-первых, создание тестов - довольно кропотливая работа. Во-вторых, не все ожидания можно описать в пригодном для машины виде. Например практически невозможно описать ожидания от GUI. В-третьих, единичный тест - это всего лишь маленький частный случай. Даже большой набор тестов - просто большой набор маленьких частных случаев. Не надо думать, что если все тесты проходят, то в программе нет ошибок. Ибо доказательство методом неполной индукции не является строгим. Невозможно описать все частные случаи, поскольку это займет слишком много времени. Однако, цитируя Мартина Фаулера, "лучше выполнить неполный набор тестов, который выявит большинство ошибок, чем не выполнить никаких тестов вообще".

Итак, мне очень захотелось начать создавать тесты для той конфигурации 1С, которую я сопровождаю (а Вам?). Однако, для автоматического тестирования нужны инструментальные средства (программы), а для 1С их найти не удалось. Пришлось взяться самому. Эта маленькая разработка гордо несет громкое имя FuncTest (Functional Tester). Она пригодна для хранения и проверки ожиданий для проведения документов (проводки и движения регистров оперативного учета), а так же для выполнения отчетов.

Текущую версию FuncTest можно скачать тут. Это все еще бета-версия, но ее уже можно использовать в реальной работе (лично я так и делаю).