Тестване на сценарий в помощ на програмиста 1C

заден план

На пазара има много мощни и усъвършенствани инструменти за тестване на потребителски интерфейс. Има специални скриптови езици, много документация и методологии. С други думи, „Имате проблем? Има решение!".

И така, като се има предвид: географски разпределена група от 1C разработчици до 10 души, средно до 5 активни проекта, главно разработване на персонализирани решения без използване на типични 1C продукти.

След изучаване на редица системи от инструменти на западни доставчици, както и тестване на сценарии от 1C версия 3.0 и xUnitFor1C, изглеждаше, че все още не сме умствено узрели за прилагане на тези технологии. Времето мина, а ние все още не можем да пораснем. В същото време всичко вътре изискваше и изискваше поне някакво решение.

След събиране на стари записи отново беше съставен списък с изисквания за потенциален софтуерен продукт:

Решението трябва да е в облака
Тестовата база за всички разработки трябва да бъде една и съща
Трябва да има контрол на достъпа до приложенията (всеки програмист има собствен пул за разработка)
Разработката и изпълнението на теста трябва да са в една и съща IDE
Скриптовете трябва да бъдат програмирани, а не написани от действия на потребителя
Желателно е тестовият език за програмиране да бъде подобен на езика 1C
Тестовете трябва да се стартират с един бутон, без предварителни манипулации, компилации, сборки, качвания, изтегляния и т.н.
В процеса на писане на тест трябва да е възможно да се анализира структурата на прозорците и атрибутите на тестваното приложение по отношение на модела на управлявания интерфейс 1C и това трябва да бъде в програмата, в която се разработва самият тест. Трябва да е възможно да се получат свойствата на полетата на тестваното приложение при преминаванеконтролно дърво в базата за тестване - тестваното приложение трябва да отговори и да покаже къде е този контрол.
Референтна база не трябва да се използва за тестване на бизнес логиката
За да изработите теста, не трябва да има специално подготвена база, всички тестове трябва да могат да работят и да създават всичко, от което се нуждаете сами

Разбира се, списъкът далеч не е пълен и до известна степен присъства и в други софтуерни продукти. Може да изглежда като младежки максимализъм, но едва когато всички тези условия бяха изпълнени в един продукт, видяхме, че е възможно да приложим тестване на сценарий в нашата ситуация. Колегите може да не са съгласни с мен, но аз съм на мнение, че един от ключовите проблеми в качеството и количеството на тестовете като такива е колко бързо и удобно могат да се правят тези тестове в режим на непрекъснато разработване на приложения.

Вероятно минаха още шест месеца и най-накрая реших да започна да разработвам следващия тестов мотоциклет (наричан по-нататък тестер) в бавен опционален режим и ето какво се получи от него.

Как изглежда

В резултат на това се роди приложение, базирано на 1C, в което се пишат и изпълняват тестове на сценарии за решения, базирани на 1C. Ежедневната употреба е нещо подобно: тестерът е отворен при програмиста на втория монитор през целия ден. В базата данни на проекта мениджърът посочва необходимия набор от тестове, които проектът трябва да покрие.

Има и редица стандартни, задължителни тестове, които трябва да бъдат изпълнени от програмиста за всяка задача. Например, ако документът е въведен въз основа на, трябва да има входен тест въз основа на. С други думи, програмистът знае кои тестове трябва да бъдат създадени.

Кога се пишат тестове?

На практика писането на тестове в половината от случаите се случва в процесаразвитие (много удобно за рутинна автоматизация, когато трябва да повтаряте едни и същи действия всеки път, когато рестартирате приложението). В другата половина - след. Както опитният читател сигурно е забелязал, тази ситуация трудно може да се нарече класическа BDD.

Пример за тестване

Да кажем, че има проект „Разработване на комплект за компилиране на документи“. Този документ изисква формуляр за списък със складов филтър. Общата концепция за това как работят списъците в това решение е възприета, както следва: ако е зададен филтър, в допълнение към избирането на документи по стойността на филтъра, се изисква стойността за избор да служи като стойност по подразбиране при въвеждане на нов документ от този формуляр. По този начин, ако складът е инсталиран, той трябва да се инсталира автоматично при въвеждане на нов документ.

Само на пръв поглед изглежда, че не е необходим тест за такъв сценарий, но предвид разнообразието от опции за въвеждане на документи полето Склад може да приема различни стойности. В крайна сметка документът може да бъде копиран или потребителят има друга фирма, посочена в настройките по подразбиране, а избраният във филтъра склад не е нейна организационна единица. По един или друг начин, така ще изглежда тестът (ние имаме чужденци в нашия екип, така че самият тестер е написан на английски, а самото приложено решение е предназначено за американски клиенти):

Отгоре - приложението в процес на разработка, отдолу - тестерът, в режим на тънък клиент, тестовата база данни в облака. Кодът, който виждате, е написан на езика 1C. Кодът на скрипта взаимодейства с работещото клиентско приложение чрез обвивките на метода на тестваното приложение 1C, например, така изглежда методът Choose (...);

Опитах се да внедря почти всички интерфейсни операции в тестера, но дори и да е необходимо нещоспецифичен, винаги можете да получите обекта на тестваното поле и да изпълните всякакви методи върху него, които са внедрени в модела на тестваното приложение.

Да преминем към по-интересни сценарии.

Тестова връзка

За да разработим сценарий за създаване и провеждане на документ за сглобяване, както в предишния пример, трябва да имаме много допълнителни данни: необходимия състав на директории, баланс на материалите в склада, което най-малкото означава наличието на някакъв вид пристигане в склада. Както казах по-рано, ние решихме за себе си, че тестовете трябва да се извършват в условия, при които референтната база не съществува, има само първоначалното изображение на приложението, където има поне един потребител с администраторски права, попълнени класификатори и стойности по подразбиране за удобно първоначално потребителско изживяване.

Въпреки това, писането на пълен скрипт всеки път, който ще създаде всички необходими данни „по пътя“, ще бъде неефективно. Бих искал да разработя параметризиран тест, който не само знае как да направи нещо, но и приема параметри. Например, за да създадете разписка в базата данни, трябва да има тест, който да я създаде. И нищо не ни пречи да направим този тест параметризиран и да предадем всички необходими данни в него, например на коя дата да направим разписката, кой склад и какви материали / услуги да получим. От своя страна, тестът за създаване на касова бележка ще използва тестове за създаване на склад, материали, които ще се очакват в параметрите тип опаковка, тип, коефициенти на преобразуване и т.н.

Тъй като нашето приложение е облачно и тестовата база е унифицирана, всеки програмист, разработвайки определен тест, може да го параметризира към нещо в процеса на директно писане на тест, отваряйки го за широко използване от други програмисти.

Ето пример за това как тестът за създаване на сглобяване се подготвя за прием:

(цените, сумите и количествата са посочени като низове, за да се избегнат проблемите с фалшиви положителни резултати от проверката на теста, ако се изпълнява на друг език, където триадният разделител и дробната част например може да се различават)

В процеса на изпълнение на този тест ще бъдат изпълнени редица други тестове, които ще създадат всичко необходимо, за да може да се тества Assembling като такъв. Ето какъв ще бъде резултатът в базата данни:

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

В допълнение към факта, че всички бутони бяха „щракнати“ и полетата бяха „избрани“, събитието за тестване щеше да остави дълбок белег в сърцето ми, ако не бях тествал резултатите от механизмите за публикуване на документи и не бях оценил текущата счетоводна ситуация в базата данни.

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

Ето пример за отчет за движение на документ в тестваното приложение:

Ето как тестерът ще провери тези движения:

Червените области са важни за проверка. В допълнение към областите, в тестера можете да зададете валидиране на полето според шаблон.

Примерни проверки

Често има проблем с проверката на обекти от същия тип. Например, в половината от случаите формулярите на документи имат таблична част и често се допускат програмни грешки при копиране на редове, изтриване на първия ред или въвеждане и отказ за въвеждане на първи / следващи редове. За тази цел е възможно да се разработи тестов метод, който няма самостоятелен скрипт, а се използва само за повикване на място. Това е многоудобно, тъй като с течение на времето такива тестове могат да бъдат изградени чрез добавяне на други тестови елементи там, което води до автоматично разширяване на покритието на приложенията поради широкото използване на такива тестове.

Контрол на грешките

Има поне три вида грешки, които бихме искали да контролираме. Първият тип са грешки в кодирането, като деление на нула, достъп до несъществуващо свойство или метод. Вторият тип грешки са грешки в логиката, например, когато щракнете върху бутона, формата трябва да се затвори, но това не се случва, или когато поставите отметка, част от формата трябва да стане недостъпна или невидима. И третият тип грешки, грешки в бизнес логиката, например, когато се отписва материал от склад, не беше възможно да се определи наличието му в базата данни. И трите вида грешки могат да бъдат отработени в тестера. Когато бъде задействан, тестерът регистрира изключение, записва го в дневника и може да покаже стека на повикванията, например, така:

Бяха внедрени и редица методи за обработка на грешки в бизнес логиката. Например, вашият тест умишлено иска да копира повече материал и искате да проверите дали съобщението ще бъде формирано правилно или дали изобщо ще бъде формирано.

Ето пример за изпълнение на такава проверка в един от тестовете:

Дървовиден анализ на елементите

Тестерът може да чете визуалните обекти на тестваното приложение. Това е удобно и понякога просто необходимо за писане на скрипт, особено за многоезични решения, където имената на бутоните зависят от езика на потребителя и трябва да използвате вътрешен идентификатор, за да изработите интерфейса (освен ако, разбира се, задачата не е да проверите синтаксиса на етикетите на бутоните). Ето пример за това как тестерът представя прочетените данни:

Заключение

Като цяло се оказамалък велосипед в помощ на програмиста 1C. Положителните характеристики на програмата включват следното:

Тестерът е лесен за инсталиране и конфигуриране
Първоначално е многопотребителски (потребителите също се създават в тестера, в административната подсистема)
Не изисква специални познания за писане на тестове
Позволява ви да реализирате сложни сценарии с бизнес логика
Позволява ви да съхранявате хиляди тестове за различни проекти в една база данни и да ги „използвате повторно“. Например, можете да създадете тест за намиране на документ в списъка по номер, който е общ за всички проекти. Или ако клиентската база е внедрена на базата на някакво стандартно решение, за което вече има тестове, можете да проверите клиентската база, като извикате всички родителски тестове, плюс тестове, специално създадени за клиента

И разбира се, много все още не са изпълнени:

Няма график за пробно изпълнение
Няма разширена система за анализ, графики и отчети за резултатите от тестовете
Без автоматични съобщения и известия за това какво се е счупило, кой е счупил и защо
Няма връзка с хранилища и версии на тестове

Тестерът е отворен и безплатен, желателно е да го стартирате от 8.3.7. Вътре има малко помощ (изтеглена от интернет), обвивките на методите са налични и на български, dt-shnik може да се изтегли от тук. Има няколко примера за accounting corp 3.0.

Успех с тестовете приятели и благодаря за вниманието!