Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactoring proposition: run_tests.py, unittests modules #685

Open
KonsKo opened this issue Sep 24, 2024 · 1 comment
Open

Refactoring proposition: run_tests.py, unittests modules #685

KonsKo opened this issue Sep 24, 2024 · 1 comment
Assignees
Labels
enhancement New feature or request Infrastructure The framework reworking and extensions
Milestone

Comments

@KonsKo
Copy link
Contributor

KonsKo commented Sep 24, 2024

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.

@RomanBelozerov RomanBelozerov added enhancement New feature or request Infrastructure The framework reworking and extensions labels Sep 27, 2024
@KonsKo KonsKo self-assigned this Oct 1, 2024
@KonsKo
Copy link
Contributor Author

KonsKo commented Oct 3, 2024

In the scope of the task:

  • modules from helpers and framework directories were sorted and placed in related correct places.
  • we (wil) have many different files in directory test_suite such flacky.py, mixins.py, checks_for_tests.py to name a few. They are kind-of-test-helpers-or-utils, and may be refactored/reworked. Now their names are not quite suitable.

@krizhanovsky krizhanovsky added this to the 1.0 - GA milestone Oct 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Infrastructure The framework reworking and extensions
Projects
None yet
Development

No branches or pull requests

3 participants