k.sosnovskikh
Find a file
2024-04-23 23:55:12 +03:00
.forgejo/workflows [#202] .forgejo: Replace old DCO action 2024-04-04 12:23:00 +00:00
src/frostfs_testlib [#211] Return response in complete_multipart_upload function 2024-04-23 23:55:12 +03:00
tests [#185] Add prometheus load parameters 2024-02-21 18:37:48 +03:00
.gitignore Add repr and str for most classes used in parametrize 2023-07-24 19:34:21 +03:00
.pre-commit-config.yaml Bump version 1.1.0 -> 1.1.1 2023-02-08 10:52:10 +01:00
CONTRIBUTING.md [#119] Renamed Github to Gitea in links 2023-11-15 13:08:58 +03:00
LICENSE Initial commit 2022-08-24 16:36:00 +03:00
Makefile Add repr and str for most classes used in parametrize 2023-07-24 19:34:21 +03:00
pyproject.toml [#191] Credentials work overhaul 2024-03-11 19:23:10 +03:00
README.md [#119] Renamed Github to Gitea in links 2023-11-15 13:08:58 +03:00
requirements.txt [#98] Small dependency cleanup 2023-10-17 17:45:23 +03:00

frostfs-testlib

This library provides building blocks and utilities to facilitate development of automated tests for FrostFS system.

Installation

Library can be installed via pip:

$ pip install frostfs-testlib

Configuration

Some library components support configuration that allows dynamic loading of extensions via plugins. Configuration of such components is described in this section.

Reporter Configuration

Reporter is a singleton component that is used by the library to store test artifacts.

Reporter sends artifacts to handlers that are responsible for actual storing in particular system. By default reporter is initialized without any handlers and won't take any actions to store the artifacts. To add handlers directly via code you can use method register_handler:

from frostfs_testlib.reporter import AllureHandler, get_reporter

get_reporter().register_handler(AllureHandler())

This registration should happen early at the test session, because any artifacts produced before handler is registered won't be stored anywhere.

Alternative approach for registering handlers is to use method configure. It is similar to method dictConfig in a sense that it receives a config structure that describes handlers that should be registered in the reporter. Each handler is defined by it's plugin name; for example, to register the built-in Allure handler, we can use the following config:

get_reporter().configure({ "handlers": [{"plugin_name": "allure"}] })

Hosting Configuration

Hosting component is a class that represents infrastructure (machines/containers/services) where frostFS is hosted. Interaction with specific infrastructure instance (host) is encapsulated in classes that implement interface frostfs_testlib.hosting.Host. To pass information about hosts to the Hosting class in runtime we use method configure:

from frostfs_testlib.hosting import Hosting

hosting = Hosting()
hosting.configure({ "hosts": [{ "address": "localhost", "plugin_name": "docker" ... }]})

Plugins

Testlib uses entrypoint specification for plugins. Testlib supports the following entrypoint groups for plugins:

  • frostfs.testlib.reporter - group for reporter handler plugins. Plugin should be a class that implements interface frostfs_testlib.reporter.interfaces.ReporterHandler.

Example reporter plugin

In this example we will consider two Python projects:

  • Project "my_frostfs_plugins" where we will build a plugin that extends testlib functionality.
  • Project "my_frostfs_tests" that uses "frostfs_testlib" and "my_frostfs_plugins" to build some tests.

Let's say we want to implement some custom reporter handler that can be used as a plugin for testlib. Pseudo-code of implementation can look like that:

# File my_frostfs_plugins/src/foo/bar/custom_handler.py
from contextlib import AbstractContextManager
from frostfs_testlib.reporter import ReporterHandler


class CustomHandler(ReporterHandler):
    def step(self, name: str) -> AbstractContextManager:
        ... some implementation ...

    def attach(self, content: Any, file_name: str) -> None:
        ... some implementation ...

Then in the file pyproject.toml of "my_frostfs_plugins" we should register entrypoint for this plugin. Entrypoint must belong to the group frostfs.testlib.reporter:

# File my_frostfs_plugins/pyproject.toml
[project.entry-points."frostfs.testlib.reporter"]
my_custom_handler = "foo.bar.custom_handler:CustomHandler"

Finally, to use this handler in our test project "my_frostfs_tests", we should configure reporter with name of the handler plugin:

# File my_frostfs_tests/src/conftest.py
from frostfs_testlib.reporter import get_reporter

get_reporter().configure({ "handlers": [{"plugin_name": "my_custom_handler"}] })

Detailed information about registering entrypoints can be found at setuptools docs.

Library structure

The library provides the following primary components:

  • blockchain - Contains helpers that allow to interact with neo blockchain, smart contracts, gas transfers, etc.
  • cli - wrappers on top of frostFS command-line tools. These wrappers execute on a shell and provide type-safe interface for interacting with the tools.
  • hosting - management of infrastructure (docker, virtual machines, services where frostFS is hosted). The library provides host implementation for docker environment (when frostFS services are running as docker containers). Support for other hosts is provided via plugins.
  • reporter - abstraction on top of test reporting tool like Allure. Components of the library will report their steps and attach artifacts to the configured reporter instance.
  • shell - shells that can be used to execute commands. Currently library provides local shell (on machine that runs the code) or SSH shell that connects to a remote machine via SSH.
  • utils - Support functions.

Contributing

Any contributions to the library should conform to the contribution guideline.