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

Вступление.

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

Разработка на платформе 1С: Предприятие — не самый сложный процесс. Самое сложное — принять концепцию написания кода на родном языке :)
Но не смотря на то, что в 8й версии платформы был совершён положительный качественный скачок в устройстве платформы и встроенного языка (например, появление концепции MVC для объектов метаданных конфигурации) многие народные кодеры продолжают выдавать мегабайты «мусора», который каким-то чудом работает в рамках того, что смог/успел проверить такой кодер.
У меня нет богатого «опыта» работы в различных франчайзи, у меня за все годы перед глазами только опыт единственного отдела, который выпускает коробочные продукты, продукты продаются, клиенты находят баги, терроризируют техподдержку, техподдержка бегает к разработчикам, разработчики радостно фиксят найденные баги, попутно внося разнообразные новые, короче говоря — работа есть всем и хватит её надолго.
Сколько времени уходит на фикс багов, а сколько на создание нового функционала — пропорция известна лишь приблизительно. Баги, найденные клиентами, воспринимаются как неизбежное зло, и для уменьшения времени на их исправление прибегают к усиленному ручному тестированию релизов и наймом/воспитанием грамотных разработчиков. Ручное тестирование отделом QA это достаточно трудоёмко и нет возможности точно определить золотую середину соотношения глубины тестирования к потраченному на тестирование времени. Про наличие огромного количества талантливых разработчиков вообще говорить не приходится.
Во «взрослых» языках программирования подобные проблемы стараются решать повсеместным тестированием. Начиная с уровня разработчика — unit-тестами, далее функциональными и регрессионными, и заканчивая интеграционными тестами. В особо интересных случаях тесты запускаются на каждый чих коммит в определённую ветку репозитория.
К сожалению фирма «1С» не балует разработчиков на своей платформе какими-либо достойными инструментами, хорошо, хоть репозиторий/хранилище сделали.
Несколько лет назад, приступая к новому проекту, лично мне надоели регулярные удары одними и теми же граблями по лбу. С руководством было оговорено время на разработку своей наколенной системы тестирования в том виде как я её видел и работа закипела.

Введение

Продолжая разрабатывать «pod» в определённый момент приходит понимание, что проект становится большим и похож на лапшу состоит из нескольких логических частей. Чем раньше приходит такое понимание, тем проще выделить различные сущности одного проекта в отдельные блоки. Например, одна часть проекта отвечает за установку соединения с сервером, другая сериализует объекты в JSON и наоборот, третья взаимодействует с UI и т.п. Каждую такую сущность можно выделить отдельным модулем, называемым «subspec» (для простоты изложения далее буду использовать слово «модуль»). Такой подход не только поможет гибче управлять разработкой «pod»'а, но так же даст пользователям вашего «pod»'а возможность использовать только нужные им модули, не захламляя свои проекты ненужным кодом.

Нельзя не упомянуть опубликованные ранее статьи по этой теме — введение в Cocoapods и краткое резюме по созданию своего «pod»'а.
Последняя указанная статья дала толчок в нужном направлении, но не хватало знаний для полного понимания поданной информации. Цель данной статьи — максимально подробно описать процесс создания и использования своего собственного CocoaPod'а, далее для краткости — «pod». Ну и упорядочить свои познания в данной области.