tempesta-tech / tempesta-test

Test suite for Tempesta FW
11 stars 4 forks source link

Refactoring proposition: run_tests.py, unittests modules #685

Open KonsKo opened 1 month ago

KonsKo commented 1 month ago

We discussed some framework components over a phone call and I would like to do some propositions regarding the code structure.

  1. Place all modules that works with unittest library into separate directory for example test_engine. Currently, there are several existed candidates to move: /framework/tester.py, /helpers/shell.py (at least logic for the mentioned library), run_tests.py (this file is required extra work). Creating the new directory would help everyone (especially new users) understand the codebase easily.

  2. File run_tests.py This is the main entry point for the test run, but the file contains a lot of different logic and should be refactored.

    • all logic related to tests discovering, loading and filtering should be placed in separate module under the directory mentioned in the point 1 (unittest library has some implemented classes/methods for this purposes under the hood, we need to adjust/customize it for our purposes.).
    • all logic related to tests running should be placed in separate module under the directory mentioned in the point 1 (unittest library has some implemented classes/methods for this purposes under the hood, we need to adjust/customize it for our purposes.).
    • all logic related to tests disabling should be placed in separate module under the directory mentioned in the point 1.
    • command line arguments processing, we may leave the logic in the file, but, maybe, we need to update it, for example, by using [argparse](https://docs.python.org/3/library/argparse.html), this is more suitable for such purposes.
    • all constants/default parameters may be placed in separate module, for example constants.py (currently, some of the variables are stored in run_config.py)
    • monitoring (memory checks, for example) and requirements (root privileges, for example) related logic may be placed in separate modules

Everything of this would help us to keep the codebase clean and structured.

This is the proposition by nature, and the implementation may be different, but I think, the whole idea is clear.

The task may be break down into several small parts.

KonsKo commented 3 weeks ago

In the scope of the task: