Для инициализации метаданных теста, вначале каждого теста должен быть вызов:
Call ( “Common.Init” );
Сами метаданные задаются в справочнике приложений, в формате JSON. Получение JSON файла читайте в справке.
Если у объекта есть печатная форма – она должна тестироваться.
Для проверки бизнес-логики (движений и проводок документа) нужно использовать отчет по движениям документа. Отчет о движениях документа нужно проверять не весь, а только значимую часть, поэтому части отчета, где содержаться значения реквизитов и табличных частей, в общем случае, можно удалять.
Пример такого тестирования см. Documents.WriteOff.TestCreation.Logic > вкладка Template.
Если у объекта несколько печатных форм, а также логика проведения, такие проверки необходимо делать методами, подчиненными самому тесту.
Пример см. Document.WriteOff.TestCreation.*. Внутри TestCreation есть два подчиненных метода: Logic и PrintForm
Запуск тестирования производить от пользователя с English интерфейсом.
Все разрабатываемые тесты должны опираться на значения по умолчанию, соглашения и предоставляемые начальной базой данных, данные.
Предполагаются следующие допущения:
У пользователя задана организация по умолчанию
В системе включены все функциональные опции
Точность количества = 0 знаков.
Система тестирования не задействует понятие эталонной базы. Все тесты тестируют сами себя.
Тесты должны при необходимости создавать необходимые для своего тестирования данные самостоятельно. Почти в каждом случае, такие данные должны быть уникальными и по соглашению, такая уникальность достигается путем добавления к наименованию текущей даты и времени. Например, если тесту нужен товар, где должна быть задана упаковка с 15 единицами внутри, тогда такой тест должен сам создать такой товар, а не полагаться на его наличие в базе данных. Считается, что рост данных не будет значительным, а при необходимости, база программиста может быть «обнулена» путем загрузки начальной базы.
Все разрабатываемые тесты должны быть выполнимы на обнуленной базе (это следует из того, что при необходимости тесты сами создают себе данные).
По окончании создания теста, он должен быть включен в глобальный тест Testing, который находится в корне дерева тестов. Важно, что включены должны именно самостоятельные тесты, а не методы.
Для каждого справочника, используемого в тесте прямо или косвенно, должен создаваться тест для создания «типового» элемента. Наличие такого теста требуется для того, чтобы его мог запустить сторонний процесс.
Например, в группе тестов Common есть метод Common.Select. Этот метод предназначен для поиска элемента в форме списка. В случае, если методу не удастся найти элемент, будет предпринята попытка его создания. При создании элемента будет применяться соглашение следующего вида: ..Create.
Таким образом, при наличии метода создания элемента, гарантируется что при отсутствии в базе элемента справочника, он будет создан.
Подробнее о том, как работает поиск и какие параметры можно передать см. в самом коде метода Common.Select.
Примечание: при создании метода, не забывать устанавливать свойство Type = Method на вкладке Properties.
Каждый справочник, кроме служебного метода на создание элемента (п.1) должен иметь самостоятельный сценарный тест создания элемента. Соглашение следующее: Catalog..TestCreation.
Если у документа есть форма списка с отборами, необходимо разработать тест для тестирования передачи этих параметров в форму создания нового документа. Если это применимо. Примером может служить тест Document.GoodsWriteOff.ListFiltersToHead.
Необходимо наличие теста TestCreation для тестирования создания документа.
В случае, если документ используется в схеме тестирования бизнес-логики в связке с другими документами, например, для сценария: Приход -> Списание, в таком случае, в документе Приход нужно разработать метод создания документа по переданным параметрам, чтобы документ Списание мог этот документ создать и использовать в своем собственном тестировании. Важный момент в том, что такой метод, который будет создавать Приход, не должен себя тестировать, он должен просто создавать документ (потому что для отдельного тестирования создания документа приход будет тест TestCreation).
Примером такого вида теста является тест Document.WriteOff.TestCreation. Внутри теста определяется набор товаров, они создаются, приходуются и уже потом списываются. После чего, проверяется логика и печатная форма.
Если у объекта есть табличная часть, она кроме непосредственно заполнения логикой теста, должна быть стандартно протестирована методами:
Table.AddEscape
Table.CopyEscapeDelete
Пример использования этих методов см. Documents.WriteOff.TestCreation
Тест будет работать быстрее, если в качестве передаваемого имени методам Get (), Set () и прочим передавать идентификатор, а не синоним. Этим нужно пользоваться осмотрительно, потому что иногда следует проверять и сам синоним.
Если нужно, чтобы тест останавливался в определенной точке, можно использовать метод Stop ()
Бизнес-логика тестов проверяется довольно долго, при разработке сценария, может не всегда требоваться проверка логики каждый раз. Для того, чтобы отключить проверку бизнес логики, можно использовать флаг CheckLogic, например так: __.CheckLogic = false;