Allure с использованием Docker и Gitlab Pages и частично selenium

Этот текст предназначен для начинающих тестировщиков, желающих понять как делать отчеты на allure с историей тестов, также разъяснить где их хранить, чтобы в отчет мог заглянуть любой участник вашей команды.

Когда я хотел добавить в gitlab автотесты в стеке python, allure, docker, то я выяснил, что толковых статей на эту тему нет. Пришлось разбираться самостоятельно и как результат проб и ошибок появилась эта статья, которая скорее является гайдом, частично затрагивающим написание тестов, но наибольший фокус именно на выстраивании инфраструктуры. Если у вас уже написаны тесты на allure, то вы сразу можете переходить к разделу настройки инфраструктуры. Отмечу, что текст НЕ затрагивает написание UI тестов, но я затрону инфраструктуру для них в отдельном блоке.

Здесь не описаны лучшие практики по написанию тестов и выстраиванию инфраструктуры. Скорее ознакомление с тем, как можно все это организовать. Примеры выполнены на windows, на других системах подход примерно такой же.

Этот гайд предполагает, что у вас уже установлен python, настроен пустой репозиторий, куда вы будете отправлять свой код. При чтении статьи не обязательно знать pytest, но очень желательно знать что из себя представляет фикстура, как ей пользоваться, а так же параметризация тестов. Для тестирования будет использован Dog API. Если вас интересует локальный запуск тестов через gitlab, то вам необходимо установить docker.

Если у вас не установлено вышеперечисленное ПО, то ниже вы можете найти полезные ссылки:

• Установка Python
• Установка Allure Если вы хотите генерировать отчеты локально. В данной статье такой метод не рассматривается.
• Скачать PyCharm Community
• Настройка ssh в git для отправки кода в gitlab
• Pytest — краткое руководство

#selenium

What is GEEK

Buddha Community

Allure с использованием Docker и Gitlab Pages и частично selenium

Этот текст предназначен для начинающих тестировщиков, желающих понять как делать отчеты на allure с историей тестов, также разъяснить где их хранить, чтобы в отчет мог заглянуть любой участник вашей команды.

Когда я хотел добавить в gitlab автотесты в стеке python, allure, docker, то я выяснил, что толковых статей на эту тему нет. Пришлось разбираться самостоятельно и как результат проб и ошибок появилась эта статья, которая скорее является гайдом, частично затрагивающим написание тестов, но наибольший фокус именно на выстраивании инфраструктуры. Если у вас уже написаны тесты на allure, то вы сразу можете переходить к разделу настройки инфраструктуры. Отмечу, что текст НЕ затрагивает написание UI тестов, но я затрону инфраструктуру для них в отдельном блоке.

Здесь не описаны лучшие практики по написанию тестов и выстраиванию инфраструктуры. Скорее ознакомление с тем, как можно все это организовать. Примеры выполнены на windows, на других системах подход примерно такой же.

Этот гайд предполагает, что у вас уже установлен python, настроен пустой репозиторий, куда вы будете отправлять свой код. При чтении статьи не обязательно знать pytest, но очень желательно знать что из себя представляет фикстура, как ей пользоваться, а так же параметризация тестов. Для тестирования будет использован Dog API. Если вас интересует локальный запуск тестов через gitlab, то вам необходимо установить docker.

Если у вас не установлено вышеперечисленное ПО, то ниже вы можете найти полезные ссылки:

• Установка Python
• Установка Allure Если вы хотите генерировать отчеты локально. В данной статье такой метод не рассматривается.
• Скачать PyCharm Community
• Настройка ssh в git для отправки кода в gitlab
• Pytest — краткое руководство

#selenium

Docker Explained: Docker Architecture | Docker Registries

Following the second video about Docker basics, in this video, I explain Docker architecture and explain the different building blocks of the docker engine; docker client, API, Docker Daemon. I also explain what a docker registry is and I finish the video with a demo explaining and illustrating how to use Docker hub

In this video lesson you will learn:

• What is Docker Host
• What is Docker Engine
• Learn about Docker Architecture
• Learn about Docker client and Docker Daemon
• Docker Hub and Registries
• Simple demo to understand using images from registries

#docker #docker hub #docker host #docker engine #docker architecture #api

Selenium Tool Suite - Components and Features

Selenium is an automation testing tool; it is primarily used to test websites and web applications; it is an open-source tool. With the help of Selenium, test cases can run directly in web browsers, just like a person operating the web browsers. It supports many web browsers such as Opera, Safari, Chrome, Firefox, IE, etc. There are several different sub tools to support different automation test approaches. In this article, we will learn about selenium tool suite, its components and features. So let’s start!!!

#selenium tutorials #selenium grid #selenium ide #selenium rc #selenium tool suite #selenium webdriver

Selenium Grid With Docker Swarm

In this guide, we will talk about setting up a Selenium Grid using Docker Swarm on any of the cloud services like GCP or AWS.

Let’s start with the basics first, i.e. what is Selenium Grid and Docker Swarm.

What is Selenium Grid?

Selenium Grid allows the execution of WebDriver scripts on remote machines (virtual or real) by routing commands sent by the client to remote browser instances. It aims to provide an easy way to run tests in parallel on multiple machines.

Selenium Grid allows us to run tests in parallel on multiple machines, and to manage different browser versions and browser configurations centrally (instead of in each individual test).

Selenium Grid purposes and main functionalities

1. A central entry point for all tests
2. Management and control of the nodes/environment where the browsers run
3. Scaling
4. Running tests in parallel
5. Load balancing

Now a question comes “When to use Grid”?

Generally speaking, there are two reasons why you might want to use Grid.

1. To run your tests against multiple browsers, multiple versions of browsers, and browsers running on different operating systems.
2. To reduce the time it takes for the test suite to complete a test pass.

Grid is used to speed up the execution of a test pass by using multiple machines to run tests in parallel. For example, if you have a suite of 100 tests, but you set up Grid to support 4 different machines (VMs or separate physical machines) to run those tests, your test suite will complete in (roughly) one-fourth the time as it would if you ran your tests sequentially on a single machine.

What is Docker Swarm?

Docker swarm is a container orchestration tool, meaning that it allows the user to manage multiple containers deployed across multiple host machines.

One of the key benefits associated with the operation of a docker swarm is the high level of availability offered for applications. In a docker swarm, there are typically several worker nodes and at least one manager node that is responsible for handling the worker nodes’ resources efficiently and ensuring that the cluster operates efficiently.

What are the two types of Docker Swarm mode services?

Docker Swarm has two types of services: replicated and global.

**Replicated services: **Swarm mode replicated services functions by you specifying the number of replica tasks for the swarm manager to assign to available nodes.

**Global services: **Global services function by using the swam manager to schedule one task to each available node that meets the services constraints and resource requirements.

#docker-swarm #docker #selenium #docker swarm

How GitLab Pages Uses the GitLab API to Serve Content

GitLab Pages allows you to create and host GitLab project websites from a user account or group for free on GitLab.com or on your self-managed GitLab instance.

In this post, I will explain how the GitLab Pages daemon obtains a domain’s configuration using the GitLab API, specifically on GitLab.com.

How does GitLab Pages know where to find your website files?

GitLab Pages is moving to using object storage to store the contents of your web site. You can follow the development of this new feature here.

At the time of writing, GitLab Pages uses an NFS shared mount drive to store the contents of your website. You can define the value of this path by defining the [pages_path](https://docs.gitlab.com/ee/administration/pages/#change-storage-path) in your /etc/gitlab/gitlab.rb file.

When you deploy a website using the pages: keyword in your .gitlab-ci.yml file, a public path artifact must be defined, containing the files available for your website. This public artifact eventually makes its way into the NFS shared mount.

When you deploy a website to GitLab Pages a domain will be created based on the custom Pages domain you have configured. For GitLab.com, the pages domain is *.gitlab.io, if you create a project named myproject.gitlab.io and enable HTTPS, a wildcard SSL certificate will be used. You can also setup a custom domain for your project, for example myawesomedomain.com.

For every project (a.k.a. domain) that is served by the Pages daemon, there must exist a directory in the NFS shared mount that matches your domain name and holds its contents. For example, if we had a project named myproject.gitlab.io, the Pages daemon would look for your .html files under /path/to/shared/pages/myproject/myproject.gitlab.io/public directory. This is how GitLab Pages serves the content published by the pages: keyword in your CI configuration.

Before GitLab 12.10 was released on GitLab.com, the Pages daemon would rely on a file named config.json located in your project’s directory in the NFS shared mount, that is /path/to/shared/pages/myproject/myproject.gitlab.io/config.json. This file contains metadata related to your project and custom domain names you may have setup.

{
  "domains":[
    {
      "Domain":"myproject.gitlab.io"
    },
    {
      "Domain": "mycustomdomain.com",
      "Certificate": "--certificate contents--",
      "Key": "--key contents--"
    }
  ],
  "id":123,
  "access_control":true,
  "https_only":true
}

GitLab Pages has been a very popular addition to GitLab, and over time the number of hosted websites on GitLab.com has increased a lot. On start-up, the Pages daemon would traverse all directories in the NFS shared mount and load the configuration of all the deployed Pages projects into memory. At some point in time, the Pages daemon would take over 20 minutes to load per instance on GitLab.com!

#gitlab #gitlab api #gitlab pages #api