Статья 1: Зачем всё это (версия 1 от 05.12.2007)
Зачем нужны стандарты
Обрисую всего три ситуации, в которых может возникнуть необходимость внедрения стандартов.Ситуация 1 — Просто зрелость ...
Ты уже вполне зрелый разработчик. На Платформе 8.х можешь написать всё, что угодно, в багаже у тебя огромное количество кода, перекочевавшего с 7.7. Твой стиль полностью сформирован. И очень приятно отлаживать приложения, не вчитываясь в каждую строку или мучая дебаггер, а просто оценив «рисунок» кода. Ошибка, скорее всего, будет там, где написано некрасиво.Опыт растет с каждым днем. В результате этого ты устанавливаешь сам себе правила на кодирование и переносишь из одной конфигурации в другую проверенные блоки метаданных.
Ситуация 2 — Помощнички, мать их ...
Тебе дают в помощь молодого, неопытного, горячего помощника. Он программирует раньше, чем думает. Понятие «доработать что-либо в стиле» существующей конфигурации для него неведомо. Работает, значит нормально, а следить за каждой строкой его кода просто невозможно. Правда, если не следить, то после двух-трех таких «помощников» уже и конфигурацию сопровождать с удовольствием будет невозможно.Вот и приходится вводить некоторые стандарты, обязательные для изучения новичками, хотя бы на уровне именования переменных и функций.
Ситуация 3 — Даёшь «коробочное» решение ...
Созданная конфигурация уникальна и замечательна. Она так и проситься стать «коробочным» решением. Её можно начать продавать, переведя свой ИТ департамент из разряда центра затрат в центр прибыли.И первым шагом для этого становиться соответствие конфигурации требованиям «1С: Совместимо».
Думаю, этих ситуаций достаточно для того, чтобы решить, что стандарты нужны.
Но стандартам следовать сложно
Стандарты меняются
Каждая новая конфигурация, каждое изменение платформы заставляет пересматривать некоторые приёмы и архитектурные решения.Параметры сеанса — очень удобны для создания универсальных подсистем, но, пока не появилась платформа 8.1, для более высокой производительности приходилось пользоваться глобальными переменными.
Сегодня ты используешь для глобальных функций префикс «гл», а завтра появляется понятие не глобального общего модуля и роль префикса прекрасно сможет сыграть имя самого модуля.
Стандарты надоедают и забываются
А бывает так, что просто устал. Хочется просто написать работающий код и закрыть глаза на все свои или чужие правила.Иногда стандартов становиться так много, что ты просто забываешь, что отныне, все входящие параметры, например, должны начинаться с префикса «вх» для входных и «вых» для выходных. Ты привык писать префикс «п», вот и пишешь его «на автомате».
Или еще веселее, у тебя есть очень важный справочник, ты добавляешь в конфигурацию новую двадцать пятую второстепенную роль, и она получает права на изменение данных этого справочника. Обнаруживается это, как правило, только после большого скандала.
Да мало ли что еще может быть...
Главное, что итог очень часто один. Стандарт есть, но ему никто не следует.
В каждом релизе проверочка ...
Вот и получается, что без проверки конфигурации на соответствие стандартам никак не обойтись.Ни один стандарт не может считаться жизнеспособным, если он не поддерживается тестом.
Если получится разделить разработчиков и тестировщиков качества (тут имеются в виду роли), и дать каждому один и тот же инструмент для проверки, то будет вообще всё замечательно.
Разработчик знает требования, они описаны в стандарте. Забыл, прочти заново.
Тестировщик может и не знать стандарты, но знает те тесты, которые нужно запустить перед отправкой конфигурации в рабочую среду.
Разработчик может сам, перед тем как заявить о том, что все сделано, проверить конфигурацию.
А если он этого не сделает, то тестировщик проверит конфигурацию за него и, скорее всего, «отбракует».
В каждом релизе исправлялочка?
А может взлететь своими мыслями дальше и представить, что некоторую рутинную часть работы по исправлению конфигурации можно автоматизировать?Обнаружен пустой обработчик события, так и удалить его, не мучить людей.
Может и так, вернее туда и дойдем, но сначала научимся отлавливать несоответствия.
Статья 2: Как создать свой тест (версия 1 от 07.12.2007)
С чего начинается тест
Тест не начинается с написания теста. Тест является всего лишь инструментом для достижения некоторой цели. Цель же вполне конкретна – конфигурация должна соответствовать определенному стандарту.
Задачи соответствовать всем существующим стандартам нет. Для каждой конкретной организации и даже конфигурации, может быть выбран свой набор стандартов.
Но каждый стандарт в этом наборе должен быть оформлен документально, чтобы в любой момент разработчик мог ознакомиться с обоснованием того или иного требования.
Как известно, одна и та же задача может быть решена разными путями, и периодический пересмотр типовых решений типовых задач новыми людьми может быть полезен.
Таким образом, тест не начинается с создания теста, он начинается с описания стандарта.
Краткое описание этапов создания теста
Директорий Templates содержит все необходимые шаблоны
1. Определить Категорию стандарта, определить краткое, узнаваемое название стандарта
2. Выбрать некоторое уникальное имя для всего блока (стандарт, тест, настройки)
3. Создать стандарт ИМЯ.doc из шаблона для стандарта (TestIB8x.dot)
4. Создать «скелет» теста ИМЯ.js из заготовки (TestIB8x.js)
5. Создать «скелет» шаблона файла настроек ИМЯ.xml (TestIB8x. xml)
6. Изменить тест и шаблон файла настроек под нужды стандарта.
7. Подключить новый тест к динамическому меню (\Bin\TestIB8xShExt.xml)
Статья 3: Объектное окружение теста (версия 1 от 12.12.2007)
Как почувствовать, что у нас есть
И действительно, что же у нас есть, после того, как тест скопирован из шаблона, переименован, подключен к меню, запущен на выполнение и отобразил “Init, Run, Done”.
Потенциально, у нас есть вообще всё, т.к. Windows Script Hosting проектировался как основа для работы с любыми COM-объектами. Практически, нам так много не нужно.
Сколько нам нужно объектов
Нам нужно работать с каталогами, с файлами в кодировке UTF-8, уметь запускать приложения. Это всё умеют объекты, входящие в состав WSH 5.6.
Нам нужно работать с файлами настроек, а они в формате XML, а это MSXML 4.0 или выше.
И, наконец, нам не очень хочется каждый раз изобретать структуру теста и формат лога заново. Подготовил среду, выполнил тест, зачистил среду, показал результат. По ходу тестирования вызвал из библиотеки некоторые стандартные функции, записал ход выполнения теста в лог. Обработал ошибки. Все эти возможности собраны в компоненты TestIB8x.Engine.
Возможно, когда-нибудь, мы начнем работать с версиями КС8х, тогда нам еще нужен будет пакет MS ADO. Но когда начнем, тогда и подключим, это недолго.
Как нам изучать возможности этих компонентов
Для тех, кто забыл ;-), напомню, что объектные модели, необходимых нам компонентов, можно легко смотреть в среде VBA любого офисного приложения. Мне больше по душе MS Excel.
Заходим в редактор сценариев, Сервис – Макрос – Редактор Visual Basic (Alt+F11), далее подключаем нужный нам компонент через меню Tools – References, чтобы потом рассмотреть компонент через View – Object browser.
Для WSH нам нужен компонент Microsoft Scripting Runtime
Для MSXML – Microsoft XML, версии равной или выше 4
Для ADO – Microsoft ActiveX Data Objects 2.x Library (полагаю, что равной или выше 2.8)
Для TestIB8x - TestIB8x.tlb в директории программы, Reference позволяет подключить библиотеку типов, сохраненную в файле .tlb.
Таким образом, немного визуализировать объекты, необходимые для тестирования мы можем.
Для TestIB8x есть чуть более красивая картинка
Есть и еще одна картинка, изображающая, что мы имеем при работе типового теста в плане существования объектов. На ней изображены сами объекты, в последовательности из создания.
Если картинок недостаточно
Если картинок недостаточно, то понятно, тут выход только один, чтение документации. По WSH в состав программы включен файл справки Script56.CHM. Лежит в директории Documentation.
Описание функций TestIB8x станет предметом следующей статьи, тем более что с каждым новым тестом появляются новые универсальные функции.
Этот проект, не коробочный продукт, читайте код, благо его пока не много.
