Unit-test Начало

Когда-то давно мне впервые попалась на глаза такая картинка - пирамида тестирования. Картинка описывает количественное распределение различных тестов. Потом я начал видеть ее все чаще. Именитые авторы описывали ее ценность и "правильность".

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

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

Как правило код решений на платформе 1С:Предприятие состоит из 2х частей: типовой код и код разработчика. Соотношение 80 на 20 соответственно. Если рассматривать вызовы процедур и функций через стек вызовов, то можно получить дерево вызовов. Изменённый код (он же тестируемый) находится на разных уровнях этого дерева.

Звучит достаточно просто - создал новую процедуру или изменил существующую, сохранил эталонный результат выполнения, а для ее тестирования создал процедуру с вызовом и сверил результат тестового вызова с эталонным значением.

На практике все не так однозначно. Все в один голос говорят, что вызываемый unit-тестом код должен быть изолирован от всех внешних зависимостей, в том числе от базы данных. По сути это алгоритмы "чистой" бизнес-логики выполняемая в памяти, т.е. всевозможные расчеты, вычисления, распределения. Такой логики в решениях на платформе 1С:Предприятие 8 очень мало. Поэтому исходная пирамида будет иметь другой вид, т.к. количество таких тестов будет ничтожно мало.

Кроме всего прочего код системы должна быть "правильным" образом спроектирован и распределен по логическим слоям. Этого невозможно сделать без применения при разработке методики TDD (Test-Driven Development).