Сценарне тестування на допомогу програмісту 1С

Передісторія

На ринку існують дуже потужні і розвинені засоби тестування інтерфейсу користувача. Є спеціальні мови опису сценаріїв, маса документації та методологій. Інакше кажучи, «Є проблема? Є рішення!».

Отже, дано: територіально розподілена група розробників на 1С до 10 осіб, у середньому до 5 активних проектів, в основному розробка кастомних рішень без використання типових продуктів 1С.

Після дослідження ряду інструментальних систем західних вендорів, а також сценарного тестування від 1С версії 3.0 і xUnitFor1C, складалося враження, що ми поки що ментально не доросли до впровадження цих технологій. Час минав, а ми все ніяк не можемо дорости. При цьому нутро все вимагало і вимагало хоч якогось рішення.

Піднявши старі записи, було в черговий раз складено перелік вимог до потенційного програмного продукту:

Рішення має бути хмарним
База тестів для всіх розробок має бути єдиною
Має бути контроль доступу до додатків (у кожного програміста свій пул розробок)
Розробка тестів та їх виконання має бути в одній IDE
Сценарії повинні програмуватись, а не записуватись діями користувача
Бажано, щоб мова програмування тестів була схожа мова 1С
Запуск тестів повинен проводитись по одній кнопці, без попередніх маніпуляцій, компіляцій, складання, розвантаження, завантаження та іншого
У процесі написання тесту має бути можливість аналізу структури вікон і реквізитів додатка, що тестується в термінах моделі керованого інтерфейсу 1С, і це має бути в тій програмі, де розробляється і сам тест. Повинна бути можливість отримання властивостей полів додатка, що тестується, при проході подереву контролів в базі тестування - додаток, що тестується повинен відгукуватися і показувати де цей контрол.
Для тестування бізнес-логіки не має використовуватися еталонна база
Для відпрацювання тесту, не повинна бути спеціально заготовлена база, всі тести повинні вміти працювати і створювати все що потрібно самі

Звичайно, список далеко не повний, і тією чи іншою мірою присутній в інших програмних продуктах. Може здатися юнацьким максималізмом, але при виконанні всіх цих умов в одному продукті ми бачили можливим впровадження сценарного тестування в нашій ситуації. Колеги можуть зі мною не погодитися, але я дотримуюся думки, що однією з ключових проблем якості та кількості тестів як таких є те, як швидко та зручно ці тести можна робити у безперервному режимі розробки програми.

Минуло, мабуть, ще півроку, і нарешті я вирішив розпочати у мляво-факультативному режимі розробку чергового велосипеда-тестувальника (далі — тестер), і ось що з цього вийшло.

Як це виглядає

У результаті народився додаток на базі 1С, в якому пишуться та виконуються сценарні тести для рішень на базі 1С. Щоденне використання приблизно таке: тестер відкритий у програміста на другому моніторі весь робочий день. У основі обліку проектів менеджер вказує обов'язковий набір тестів, якими має бути покритий проект.

Існує також ряд стандартних, обов'язкових тестів, які мають бути виконані програмістом для кожного завдання. Наприклад, якщо документ вводиться на підставі, повинен бути тест на підставі. Іншими словами, програміст знає, які тести мають бути створені.

Коли пишуться тести

Насправді написання тестів у половині випадків відбувається у процесірозробки (дуже зручно для автоматизації рутини, коли потрібно в кожному перезапуску програми повторювати ті самі дії). У другій половині – після. Як, напевно, зауважив досвідчений читач, таку ситуацію складно назвати класичним BDD.

Приклад тесту

Допустимо, є проект «Розробити документ Складання комплекту». Для цього документа потрібна форма списку з фільтром по складу. Загальна концепція роботи списків у розглянутому рішенні прийнята такою: якщо фільтр встановлений, крім відбору документів за значенням фільтра, потрібно, щоб значення відбору слугувало за замовчуванням при введенні нового документа з цієї форми. Таким чином, якщо склад встановлено – він має бути автоматично встановлений під час введення нового документа.

Тільки на перший погляд здається, що для такого сценарію тест не потрібен, проте, враховуючи різноманіття варіантів введення документів, поле Склад може приймати різні значення. Адже документ може копіюватися, або у користувача в налаштуваннях за замовчуванням вказано іншу компанію, і обраний у фільтрі склад не є її організаційною одиницею. Так чи інакше, ось як буде виглядати тест (у нас в колективі є іноземці, тому сам тестер написаний англійською, а прикладне рішення, що розглядається, призначене для роботи американських клієнтів):

Зверху – додаток, що розробляється, знизу – тестер, в режимі роботи тонкого клієнта, база тестів у хмарі. Код, який ви бачите, написано мовою 1С. Код сценарію взаємодіє з запущеним клієнтським додатком через обгортки методів додатка 1С, що тестується, наприклад, ось як виглядає метод Choose (…);

Я постарався реалізувати в тестері майже всі інтерфейсні операції, але навіть якщо щось потрібнеспецифічне, завжди можна отримати об'єкт поля, що тестується, і виконати над ним будь-які методи, реалізовані в моделі тестованого додатка.

Перейду до цікавіших сценаріїв.

Взаємозв'язок тестів

Для того, щоб розробити сценарій створення та проведення документа Assembling, як у попередньому прикладі, ми повинні мати масу додаткових даних: необхідний склад довідників, залишки матеріалів на складі, що, як мінімум, означає наявність якогось приходу на склад. Як я говорив раніше, ми для себе вирішили, що тести повинні виконуватися в умовах, коли еталонної бази не існує, існує тільки початковий образ програми, де є як мінімум один користувач з адміністративними правами, заповнені класифікатори, і стандартні значення для комфортної початкової роботи користувача.

Однак, писати щоразу повний сценарій, який створюватиме всі необхідні «по дорозі» дані буде неефективно. Хотілося б розробити параметризований тест, який не лише вміє щось робити, а й приймати параметри. Наприклад, для того, щоб у базі створити надходження, для цього має бути тест, який його створить. І нічого нам не заважає зробити цей тест параметризованим, і передати в нього всі необхідні дані, наприклад, якою датою зробити прихід, який склад і які матеріали/послуги приходити. У свою чергу, тест зі створення приходу, буде використовувати тести зі створення складу, матеріалів, які чекатимуть на параметри виду упаковки, тип, коефіцієнти перерахунку та інше.

Так як наша програма хмарно і база тестів єдина, кожен програміст, розробляючи якийсь тест, може у процесі прямого написання тесту до чогось параметризувати його, відкривши широкого використання іншими програмістами.

Ось приклад як тест створення Assembling готується до вступу:

(ціни, суми та кількість задаються у вигляді рядків, щоб уникнути проблем помилкового спрацьовування перевірки тесту у разі його запуску в іншій локалі, де роздільник тріад і дробової частини, наприклад, можуть відрізнятися)

У процесі виконання цього тесту буде виконано низку інших тестів, які створять все необхідне для можливості протестувати Assembling як такий. Ось приблизно, що вийде в результаті в базі:

Тестування бізнес логіки

Крім того, що всі кнопки «прокликалися» і поля «повибралися», захід з тестуванням залишив би глибокий рубець на серці, якби я не протестував результати роботи механізмів проведення документа, і не оцінив облікову ситуацію, що склалася в базі.

Я признатись довго ламав голову, як це краще реалізувати так, щоб і без еталонної бази, і щоб легко та просто. Нічого краще я не вигадав, як просто виконувати перевірку рухів документа у зв'язці з тестуванням звітності.

Ось приклад звіту з рухів документа в додатку, що тестується:

Ось як ці рухи перевірятиме тестер:

Червоні області є важливими для перевірки. Крім областей, у тестері можна задати перевірку полів за шаблоном.

Типові перевірки

Нерідко постає завдання перевірки однотипних об'єктів. Наприклад, у половині випадків у форм документів є таблична частина, і нерідко допускаються програмні помилки при копіюванні рядків, видаленні першого рядка, або введення та відмову від введення першого/наступних рядків. Для цієї мети можна розробити тест-метод, який не має самостійного сценарію, а використовується тільки для виклику за місцем. Це дужезручно, тому що згодом такі тести можна нарощувати, додаючи туди інші елементи тестування, що тягне за собою автоматичне розширення покриття програми за рахунок повсюдного використання таких тестів.

Контроль помилок

Є щонайменше три види помилок, які хотілося б контролювати. Перший вид – це помилки кодування, такі як поділ на нуль, звернення до неіснуючої властивості чи методу. Другий вид помилок - помилки в логіці, наприклад, при натисканні на кнопку форма повинна закритися, але цього не відбувається, або при установці галочки частина форми повинна стати недоступною або невидимою. І третій вид помилок, помилки бізнес-логіки, наприклад, при списанні матеріалу зі складу, не вдалося визначити його наявність за базою. Всі три типи помилок можуть бути в тестері відпрацьовані. При спрацьовуванні тестер реєструє виняток, записує його в лог і може показати стек викликів, наприклад, так:

Також було реалізовано низку методів обробки помилок бізнес логіки. Наприклад, ваш тест навмисно хоче списати більше матеріалу і ви хочете перевірити, чи правильно буде сформовано повідомлення, і чи буде воно сформоване взагалі.

Ось приклад реалізації такої перевірки в одному із тестів:

Аналіз дерева елементів

Тестер вміє зчитувати візуальні об'єкти програми, що тестується. Це зручно, а іноді й просто необхідно для написання сценарію, особливо для багатомовних рішень, де назви кнопок залежать від мови користувача, і доводиться використовувати внутрішній ідентифікатор для відпрацювання інтерфейсу (якщо, звичайно, не стоїть завдання перевірки синтаксису написів на кнопках). Ось приклад, як тестер представляє лічені дані:

Висновок

В цілому, вийшовневеликий велосипед на допомогу програмісту 1С. Як позитивні якості програми, можна відзначити наступне:

Тестер легко встановлюється та налаштовується
Він спочатку розрахований на багато користувачів (користувачі створюються також в тестері, в підсистемі адміністрування)
Не вимагає спеціальних знань для написання тестів
Дозволяє реалізовувати складні сценарії логіки
Дозволяє в одній базі тримати тисячі тестів з різних проектів та «перевикористовувати» їх. Наприклад, можна створити загальний для всіх проектів тест пошуку документа у списку за номером. Або якщо клієнтська база реалізована на основі якогось типового рішення, для якого вже є тести, можна перевіряти клієнтську базу, викликаючи всі батьківські тести плюс тести спеціально розроблені під клієнта

І, звичайно, багато ще не реалізовано:

Немає розкладу запуску тестів
Немає просунутої системи аналізу, графіків та звітів за результатом тестування
Не реалізовані жодні автоматичні розсилки та повідомлення, про те, що зламалося, хто зламав і чому
Немає зв'язку з репозиторіями та версійності тестів

Тестер відкритий та безкоштовний, запускати бажано починаючи 8.3.7. Усередині є невелика довідка (підкачується з инета), обгортки методів є українською мовою, dt-шник можна завантажити звідси. Там є кілька прикладів для бухгалтерії корп 3.0.

Вдалих вам тестів друзі та дякую за увагу!