Ease of use - Gibiscus/wiki Wiki


COTT — идеальный инструмент тестирования для менее опытных тестировщиков, которые хотят перейти от ручного к автоматизированному тестированию. Они могут начать создавать автоматизированные тесты в течение нескольких дней без знания языка программирования. Для написания тестового сценария, QA специалисту достаточно ознакомится со списком тегов (команд) - которые находятся под капотом фреймворка.

Для составления тестового сценария мы выбрали XML

Язык не зависит от операционной системы и среды обработки. XML служит для представления неких данных в виде структуры, которую мы продолжаем разрабатывать для вас, чтобы QA - специалисты писали скрипты которые будут понятны абсолютно всем членам команды.

Плюсы:

  • Легкость чтения, подача в простой форме;
  • Стандартный вид кодировки;
  • Возможность обмена данными между любыми платформами;

Структура каждого < тега > - имеет однообразный стандарт написания, за счет которого и визуализируется восприятие тестового сценария. Также мы добавили обязательное поле описания к каждому шагу теста, чтобы поощрять не только разработку, но и поддержку теста.


Structure COTT

Для начала работы с COOT вам необходимо создать директорию с ресурсами вашего проекта. В которой будут находится основные папки вашей директории и global-config - file с глобальными настройками конфигураций вашего проекта. Так как COOT - требует наличие обязательных папок которые должны лежать в структуре ваших ресурсов. В данных папках будут лежать данные для тестирования, и сами тестовые сценарии.


Folder structure

'Обязательные папки':
folderName Extension
credentials JSON
csv CSV
excel EXCEL
javascript JS
locators XML
component XML
pages XML
patches SQL
report Reporting Toll
scenarios XML
shell sh
Variations CSV

'Purpose' ⤵️
  • credentials - Folder for storing system user data for authorization within the test scenario
{
  "username": "Test",
  "password": "[email protected]"
}

  • javascript - Folder to create and store javascript
var greeating = 'Hello, World';
console.log(greeating)

  • locators - Folder where element locators are stored (For interaction with UI)

  • Внутри папки locators должны быть такие папки как:

  • component - Папка для хранения локаторов которые относятся к footer, header элементам страниц. (Рекомендуется разделять данные локаторы для структурированности и удобства использования)

  • pages - Папка в которой храняться локаторы конкретной страницы

  • (В xml файл с локаторами, который находится в папке pages - имеется возможность вызывать нужный компонент footer и header с помощью тега: <include>

component.png

<locator locatorId="registerButton">
            <id>registerLink</id>
        </locator>

Таким образом мы сможем передавать в сценарий локаторы которые находятся в папке component через xml файл pages


patches - Folder to store data for testing( датасеты в формате SQL)

INSERT INTO t_role (id, name, description, enabled)
VALUES (1, 'ADMIN', 'Owner company', true),
       (2, 'USER', 'Admin company', true),
       (3, 'SUPERUSER', 'Lawyer company', true);

report - Folder where the test pass report will be generated


scenarios - Folder for creating and storing test scripts

<scenario xmlns="http://www.knubisoft.com/e2e/testing/model/scenario">

    <overview>
        <description>Demonstration of the work of the 'assert' tag</description>
        <name>Assert</name>
    </overview>

    <tags>
        <tag>UI</tag>
    </tags>

shell - Folder for storing Shell - scripts

var="\"The content after crated a file.\""
echo "{ \"content\":" " $var }" > ./shell-1.json
rm -f ./shell-1.json

Variations - Folder in which a data set is created and stored for interacting with the UI



Global config file structure

global-config.xml - file в котором будут находится основные настройки конфигураций вашего проекта. Вы имеете возможность создавать несколько файлов конфигураций и разделять environment тестирования

Например:

  • global-config-local.xml
  • global-config-dev.xml
  • global.config.jenkins.xml

global-config.xml - XSD схема которого имеет опциональный набор тегов из коробки, что максимально упрощает процесс настройки конфигураций.

Набор основных тегов для конфигурации global.config.xml:

<stopScenarioOnFailure> 
<runScenariosByTag>
<ui>
<integrations>

<stopScenarioOnFailure> - тег который контролирует прохождение ваших тестовых сценариев.

<stopScenarioOnFailure>false</stopScenarioOnFailure>

Имеет флаг:

true ( при запуске нескольких или одного тестового сценария, и обнаружении exception в одном из, - стартер будет остановлен, с выводом ошибки, в конкретном сценарии, и на конкретном шаге )

false ( при запуске нескольких или одного тестового сценария, и обнаружении exception, стартер не будет остановлен, все сценарии и шаги будут выполняться до завершения работы стартера, с дальнейшим выводом exception для всех сценариев которые были пройдены, и получили exception.


<runScenariosByTag> - позволяет иметь возможность реализовывать глобальный запуск тестовых сценариев по определенному тегу. Предназначен для разделения запуска тестовых сценариев.

  • Создавайте свои filterTag для удобства использования

  • Назначайте уникальный тег для каждого сценария

    <runScenariosByTag enable="true">
        <tag name="UI" enable="true"/>
        <tag name="API" enable="false"/>
    </runScenariosByTag>

При конфигурации <runScenariosByTag> - у вас имеется возможность создавать свой набор тегов, и давать им имена, которые будут использоваться для разделения, и запуска тестовых сценариев по тегу.


<ui> - предназначен для настройки конфигураций UI части При раскрытии данного тега, выпадает список внутренних тегов UI, которые необходимо заполнить для настройки конфигурации. Теги внутри UI:

<browserSettings>
<takeScreenshotOfEachUiCommand>
<webElementAutowait>
<browsers>
<chrome>
<opera>
<safari>
<edge>
<firefox>
<browserType>
<localBrowser>
<browserInDocker>
<<remoteBrowser>
<chromeOptionsArguments>
<capabilities>
<baseUrl>
  • UI config

config_ui 2 (1).gif


<integrations> - предназначен для настройки интеграций с API, Database

Внутри integration tag - имеется набор интеграций, которые идут из коробки:

<apis>
<clickhouse>
<dynamo>
<elasticsearch>
<kafka>
<mongo>
<mysql>
<oracle>
<postgres>
<rabbitmq>
<redis>
<s3>
<sendgrid>
<ses>
<sqs>
  • integration config

integration_conf.gif


При выборе определенного тега, раскрывается список параметров, необходимых к заполнению для реализации интеграций.

За счет автоматизации данных тегов, вы сможете легко конфигурировать ваш global-config.xml - file, подставляя нужные значения для быстрого начала работы с проектом.

После завершения установки, и формирования global-config.xml - file, - можно приступать к изучению используемых для тестирования тегов и написанию первого тестового сценария.



UI - Scripts

Locators

Прежде чем приступить к описанию тегов которые относятся к UI , необходимо знать как создать locator, и как происходит его связь со сценарием.

Доступные типы локаторов:

  • id
  • class
  • xpath

Для создания локаторов нужно:

  • Создать файл с названием страницы или компонента (пример:loginPages.xml)
  • Внутри loginPages.xml открыть тег <locators
  • Дать уникальное имя локатору элемента
  • Указать тип локатора ( id, xpath, class )
  • Положить контент внутрь выбранного типа локатора

Пример ( быстрое видео создания локатора ) Анимация


Структура тега:

<locator locatorId="firstName">   - Уникальное имя локатора
      <id>register_account_first-name_input</id>   - Выбранный элемент взаимодействия
 </locator>

У вас возникает вопрос, каким образом происходит связь между локатором и тегами?

Продемонстрируем связь локатора с помощью тега <click>

Тег выполняющий команду ‘клик’ по выбранному элементу страницы

     <click comment = "Click on 'Login' button"  - Комментарий выполняемого действия
        locatorId="locators.firstName"/>  - Путь к нужному элементу

После значения locatorId= "" - Мы прокладываем путь к нужному нам локатору. Мы уже знаем что все созданные локаторы хранятся в папке под названием: locators, соответственно вводим имя нужной нам папки, и после используем уникальное имя локатора В нашем случае это:

'firstName'

Таким образом мы реализуем связь взаимодействия между локатором и тегами.


Теперь ознакомимся со всеми тегами которые помогут вам качественно тестировать ПО.

Global tag

The tag is the main interpreter, containing a set of all tags for interacting with the user interface, which will be described below.

An example of using the tag:

 <ui comment="Start UI scripts">

        <navigate command="to" comment="Go to base page"
                  path="/shop/"/>
        
        <wait comment="Wait for visualize a click"
              time="2" unit="seconds"/>
        
        <click comment="Click on the 'Shopizer' website link which opens in a new window" 
               locatorId="shopizer.webSiteShopizer"/>

    </ui>

UI tag's:

  • click
  • input
  • dropDown
  • navigate
  • assert
  • scrollTo
  • scroll
  • javascript
  • include
  • wait
  • clear
  • closeSecondTab
  • repeat

 <input>

Тег выполняющий команду ввода значения в выбранное поле

 <input comment="Input first name" 
     `locatorId="ownerRegistration.firstName" 
 value="Mario"/>`   -  в value - находится значение ввода ‘Mario

Также с помощью тега <input> ми имеем возможность вставить image файл нужного формата ( например добавить фото аккаунта )

Для реализации данной функции, нужное изображение должно находится в одной папке с вашим тестовым сценарием, например в папке с названием scenario

<input comment="Add profile photo" 
     locatorId="userPhoto.addProfilePhotoButton" -  Выбранный элемент взаимодействия
  value="file:Firmino.jpg"/>   -  Внутри value обозначаем что мы хотим вставить файл с помощью file: ,после вводим название файла (который находится в папке scenario )

то есть Firmino.jpg.

 <DropDown>

Тег взаимодействия с функцией ‘select’

< Данный тег применяется для select and deselect function, с возможностью взаимодействия с мультиселектом

  1. Select One Value

Выбирает одно значение из списка

   <dropDown comment="Select 'Country'" locatorId="registration.country">
            <oneValue type="select" by="text" value="Spain"/>
        </dropDown>
  1. deSelect One Values

Сбрасывает одно значение из списка

   <dropDown comment="Deselect 'Country'" locatorId="registration.country">
            <oneValue type="deselect" by="text" value="Spain"/>
        </dropDown>

Параметр by= "" - предлагает выбор взаимодействия:

  • text
  • value
  • index
  1. Deselect All Values

Сбрасывает все значения из списка

<dropDown comment="Deselect all values'" locatorId="registration.country">
            <allValues type="deselect"/>
        </dropDown>

<navigate>

Тег позволяющий выполнять навигацию по страницам UI с помощью URL

Для использования вам нужно добавить только путь к нужной странице, так как по дефолту будет использоваться ваш базовый URL который указан в настройках конфигураций.

Имеет 3 команды:

  • to
  • back
  • reload

1.NavigateTo

Навигация на страницу указанную в path=""

 <navigate comment="Go to register account page" 
                  command="to" 
                  path="/registerAccount"/>  - путь URL
  1. NavigateBack

Возврат на предыдущую страницу сценария

<navigate comment="Go to register account page"
                  command="back"/>
  1. NavigateReload

Перезагрузка актуальной страницы сценария

<navigate comment="Go to register account page"
                  command="reload"/>

<assert>

Тег позволяющий подтвердить:

Что выполненное ранее действие привело к нужному результату

  • Пример:

Вы использовали тег <navigateBack> - для возврата на предыдущую страницу.

Чтобы подтвердить выполнение данной функции, - используется тег <assert>

В качестве подтверждения понадобится создать locatorId элемента нужной страницы и пробросить его в тег <assert>

 <assert comment="Verify that the transition to the previous page was successful" 
       locatorId="billing.billingPositiveAssert"  - имя локатора элемента нужной страницы
           attribute="id">    - выбор атрибута  ( id, class, xpath, html )
           <content>
                   register_profile-photo_input    - сам элемент 
          </content>
  </assert>

<scrollTo>

Тег позволяющий скроллить страницу по определенному элементу

 <scrollTo comment="Scroll to element" 
                  locatorId="footer.registerButton"/>

<scroll>

Scroll Up or Down by pixel

  • value="" - takes default value in pixels
    <scroll comment="Scroll Down" value="1024" direction="down"/>

    <scroll comment="Scroll UP" value="976" direction="up"/>

Scroll Up or Down by percent

  • value="" - has a maximum value of 100 (when scrolling as a percentage)
    <scroll comment="Scroll Down in percent" value="60" measure="percent" direction="down"/>

    <scroll comment="Scroll Up in percent" value="80" measure="percent" direction="up"/>

<javascript>

Тег вызывающий скрипт находящийся в папке 'javascript'

<javascript comment="Apply javascript function" file="function.js"/>

 <include>

Тег позволяющий запустить ‘сценарий внутри сценария’ ( часто используется для связки разных сценариев)

Реализовано с помощью передачи пути к сценарию, который находится в определенной папке

Начало пути всегда начинается с папки scenarios, так как все папки с созданными сценариями должны хранится именно в данной папке

 <include comment="Add scenario for login to the system"
       scenario="/nameOfScenarioFolderWithSlash"/> - Путь к папке сценария который нужно запустить

( —-- image structure —-- )


 <wait>

Тег позволяющий заморозить время прохождения сценария для выполнения определенной функции которая требует ожидания - после выполнения, сценарий будет работать в обычной темпе

 <wait comment="Waiting for loading Dashboard page" 
      time="1" unit="seconds"/>  - Имеется выбор: секунды или миллисекунды

 <clear>

Тег позволяющий очистить введенные данные в полях

 <clear comment="Clear name field"  
   locatorId="updateProfile.name"/> 

 <closeSecondTab>

Тег позволяющий закрывать актуальную вкладку браузера

 <closeSecondTab comment="Check if closing 'second tab' works correctly"/>

 <repeat>

Тег позволяющий повторять любое действие которое используется в вышеуказанных тегах

   <repeat comment="Repeat action" times="5">  - количество повторений 
          <click comment="Click on 'Send button'"
            locatorId="locator.clickButton"/>
  </repeat>`


Variations

Что такое ‘variations’ в COTT?

CSV - файл, который содержит составленные QA - данные для тестирования

Variations - выполняют важную роль в написании UI автоматизированных тестов. Когда ваши QA - специалисты столкнутся с тестированием функциональности работы полей и селекторов, - с использованием ‘variations’ они смогут за короткое время подготовить необходимый набор данных, который будет находится в табличном виде внутри csv - файла, и с легкостью протестировать валидацию и основной функционал полей и селекторов.

  • Variations — эффективны для проведения «Позитивного» и «Негативного» тестирование

  • Данные очень часто упаковывают именно в таблицы, поэтому CSV-файлы очень просты и эффективны в использовании.

Пример использования:

У нас есть форма регистрации нового пользователя, которая состоит из полей:

  • First name
  • Last name
  • EmailAddress
  • Password
  • Repat Password

Структура данного csv - файла будет иметь уникальные имена полей, с перебором значений под каждое из них.


variations.png


Когда мы свяжем наш csv - файл со сценарием, - сценарий запустится 5 раз подряд, так как в таблица состоит из 5 столбцов с разными данными внутри. Каждый запуск сценария будет выполнять перебор всех значений которые находятся в данной файле.

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

Составить такой csv - файл с данными для тестирования довольно просто, так как:

CSV-файл состоит из строк с данными и разделителей, которые обозначают границы столбцов. В одном таком файле, позитивном или негативном QA - специалисты смогут перебрать все возможные наборы значений, который помогут эффективно протестировать данный функционал.


Use of variation

To include variations in a script, add the value to the schema path 'variations="fileName"


regfow.png

registerN - имя вызываемого csv файла


Пример использования variations в сценарии

 <input comment="Input first name"
    locatorId="registerAccount.firstName" 
     value="{{firstName}}"/>  в ‘value’ - использование variation


 <input comment="Input lastname" 
    locatorId="registerAccount.lastName"
     value="{{lastName}}"/>  - использование variations


 <input comment="Input email" 
    locatorId="registerAccount.emailAddress"
     value="{{emailAddress}}"/>   - использование variations


 <input comment="Input password" 
    locatorId="registerAccount.password"
     value="{{password}}"/>   - использование variations


 <input comment="Repeat password" 
    locatorId="registerAccount.repeatPassword"
     value="{{repPassword}}"/>   - использование variations


Integrations tag's

Database tag's:

  • Postgres
  • Mongo
  • Oracle
  • MySQL
  • Dynamo
  • ClickHouse
  • Redis
<postgres>

Теги взаимодействия с базой данных:

   <postgres comment="Get all user's from system" alias="shopDb" file="expected_1">
        <query>SELECT * FROM t_user</query>
   </postgres>

<mongo>
  <mongo comment="Get all user's from system" alias="shopDb" file="expected_1">
      <query>SELECT * FROM t_user</query>
  </mongo>

<oracle>
   <oracle comment="Get all user's from system" alias="shopDb" file="expected_1">
      <query>SELECT * FROM t_user</query>
   </oracle>

<mysql>
   <mysql comment="Get all user's from system" alias="shopDb" file="expected_1">
       <query>SELECT * FROM t_user</query>
   </mysql>

<dynamo>
   <dynamo comment="Get all user's from system" alias="shopDb" file="expected_1">
       <query>SELECT * FROM t_user</query>
   </dynamo>

<clickhouse>
   <clickhouse comment="Get all user's from system" alias="shopDb" file="expected_1">
       <query>SELECT * FROM t_user</query>
   </clickhouse>

<redis>
   <redis comment="Get all user's from system" alias="shopDb" file="expected_1">
       <query></query>
   </redis>

Queue tag's:

  • Rabbit
  • Kafka
  • SQS
<rabbit>
    <rabbit comment="Receive 2 times and send 1 time"
            alias="rabbit-one">
        <receive queue="queue">
            <file>expected_1.json</file>
        </receive>

        <receive queue="queue">
            <message>[]</message>
        </receive>

        <send routingKey="queue">
            <file>body_1.json</file>
        </send>
    </rabbit>

<kafka>
  <kafka comment="Receive then send and receive 2 time"
           alias="kafka-one">
        <send topic="queue2" correlationId="343gfrvs-dh4aakgksa-cgo60dmsw-sdf4gj62">
            <file>body_2.json</file>
        </send>

        <send topic="queue3" correlationId="dfskogdfa9sd-rekjdfnkv-sdfkjewnd8-erkfdn">
            <file>body_4.json</file>
        </send>

        <receive topic="queue2" timeoutMillis="1200">
            <value>
                [ {
                "key" : null,
                "value" : "{\n \"squadName\": \"Still rule cool\",\n \"homeTown\": \"Metro Tower\",\n \"formed\":
                2018,\n \"secretBase\": \"Rower\",\n \"active\": false\n}",
                "correlationId" : "343gfrvs-dh4aakgksa-cgo60dmsw-sdf4gj62",
                "headers" : { }
                } ]
            </value>
        </receive>

<sqs>
  <sqs comment="Compare message from empty queue with file content"
         alias="queue_one"
         queue="queue">
        <receive>expected_1.json</receive>
  </sqs>

Email Services:

  • SES
  • Sendgrid
<ses>
   <ses comment="Sending a message to the email"
         alias="ses_one">
        <destination>[email protected]</destination>
        <source>[email protected]</source>
        <message>
            <body>
                <html>Amazon SES test</html>
                <text>Hello World</text>
            </body>
            <subject>TITLE</subject>
        </message>
    </ses>

<sendgrid>
    <sendgrid comment="Sending a message to the email from file"
              alias="sendgrid_one">
        <post url="mail/send">
            <response code="202"/>
            <body>
                <from file="body1.json"/>
            </body>
        </post>
    </sendgrid>

Object storage:

  • S3
<s3>
   <s3 comment="Upload json file to the bucket"
        alias="bucket"
        key="/com/tool/integration-testing/expected_2.json">
        <upload>expected_2.json</upload>
    </s3>

Search system:

  • ElasticSearch
<elasticsearch>
    <elasticsearch comment="Execute elasticsearch commands - get list of indexes"
                   alias="elastic_one">
        <get url="/_cat/indices">
            <response file="expected_1.json">
                <header name="content-length" data="0"/>
            </response>
        </get>
    </elasticsearch>


Multidatasets

COOT - имеет возможность выполнять накатку данных в базу данных, используя такие расширения как:

Все тестовые данные хранятся в папке Dataset

  • sql
  • csv
  • xlsx
  • partiql
  • bson

Migrations

Migration tag's:

  • migrate
  • csv
  • excel
<migrate>
  • Тег migrate взаимодействует со всеми существующими реляционными базами данных
    <migrate comment="Add data for database" alias="mySql">
        <patches>dataset.sql</patches>
    </migrate>

<csv>
    <csv comment="Add CSV dataset to db" alias="postgres">
        <csvFile>datasetPostgres.csv</csvFile>
    </csv>

<excel>
<excel comment="Add data for database" alias="oracle">
    <excelFile>central.xlsx</excelFile>
</excel>


REST API - Scripts

  • <var>
  • <http>
  • <auth>

Var

Переменная - поименованная или адресуемая иным способом область памяти, которую можно использовать для доступа к данным.Переменная простыми словами — это хранилище данных. Сюда можно положить какое-то значение (например, число, строку или другой тип данных). В переменных хранятся определенные данные, которые можно впоследствии использовать в программе.

Переменная гибка:

  • в ней можно хранить информацию;
  • можно из неё извлекать информацию, что не повлияет на значение самой переменной;
  • в неё можно записать новые данные.

Для того, чтобы создать переменную, необходимо ее объявить (зарезервировать ячейку памяти под определенные данные)

How to create a variable in COTT?

  • Предположим, в нашем тестовом сценарии имеется шаг <postgres> когда мы обращаемся в базу данных для того чтобы отобразить данные из определенной таблицы и вытащить токен авторизации.
  <postgres comment="Get token and user_id from t_one_time_token table" file="expected_7.json" alias="central">
        <query>SELECT token, user_id
            FROM t_user_one_time_token ORDER BY ID DESC LIMIT 1
        </query>
    </postgres>
  • После выполнения данного запроса мы получим actual_file_1.json c ответом базы, и перенесем его в expected_1json

Объявление переменной с излечением данных:

     <var comment="Created token var" name="TOKEN"> 
          <jpath>$.[0].content.[0].token</jpath> - внутренний тег с помощью которого мы извлекаем нужные нам данные из expected_file
     </var>
  • name="TOKEN" - Имя обьявленной переменной <jpath>$.[0].content.[0].token</jpath> - способ извлечения данных из json (expected file)

Пример передачи переменной в http - запросе

<http comment="Get user profile" alias="API">
        <get url="/api/v1/profile">
            <response code="200" file="expected_1.json"/>
            <header name="Authorization" data="Bearer {{TOKEN}}"/> - использование переменной
        </get>
   </http>

Structure HTTP

Структура HTTP запроса имеет в себе все основные возможности инструментов для тестирования API.

HTTP в тестовом сценарии

  <http comment="Check the ability login system" alias="API">  - описание действия + alias API
      <post url="/api/v1/login"> - указание вида запроса + используемый эндпоинт
        <response code="200" file="expected_1.json"/>  - код ответа + ожидаемый результат
          <body> 
                  <from file="request_1.json"/> - передача request body
          </body>
       </post>
   </http>

   <var comment="Get JWT token from previous expected_file" - создание переменной
         name="profile"
         path="$.body.token"/>

   <http comment="Get user profile" alias="API">
        <get url="/api/v1/profile">
            <response code="200" file="expected_1.json"/>
            <header name="Authorization" data="Bearer {{profile}}"/> - использование переменной
        </get>
   </http>

Methods:

  • GET
  • POST
  • PUT
  • PATCH
  • DELETE
  • OPTIONS
  • HEAD
  • TRACE

Response code

  • 1xx
  • 2xx
  • 3xx
  • 4xx
  • 5xx

Request file

{
  "attributes": [
    {
      "id": 4
    }
  ],
  "product": 1,
  "quantity": 1
}

Expected Result

{
  "body": null,
  "errors": {
    "code": [
      "Forbidden"
    ],
    "message": [
      "Access is denied"
    ]
  },
  "debugInfo": {
    "requestId": "p(any)",
    "stackTrace": null
  }
}

Comparison

actual.png


После выполнения каждого HTTP - запроса, comparison генерирует actual_file в котором содержится ответ API в json формате с кодом ответа и данными.

actual_file - генерируется для того чтобы QA - специалист на лету понимал как система отреагировала на данную проверку. Если актуальный результат устраивает QA, то все данные из actual_file - тестировщик переносит в файл под названием expected_file ( который стоит в структуре http - запроса как ожидаемый результат проверки, для того чтобы данный тест проходил успешно.

HTTP - в COTT, дает возможность в считанные минуты провести смоук (и убедиться, что ничего важного не сломалось),проводить модульное и интеграционное тестирование, выполнить одни и те же тесты с разнообразными наборами входных данных или быстро проделать какие-либо вспомогательные действия по созданию тестовых данных и ситуаций.


Create HTTP - scripts

gif.gif


Function authentication

In progress



⚠️ **GitHub.com Fallback** ⚠️