You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We discussed some framework components over a phone call and I would like to do some propositions regarding the code structure.
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.
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.
The text was updated successfully, but these errors were encountered:
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.
We discussed some framework components over a phone call and I would like to do some propositions regarding the code structure.
Place all modules that works with
unittest
library into separate directory for exampletest_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.
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.
1
(unittest library has some implemented classes/methods for this purposes under the hood, we need to adjust/customize it for our purposes.).1
(unittest library has some implemented classes/methods for this purposes under the hood, we need to adjust/customize it for our purposes.).1
.[argparse](https://docs.python.org/3/library/argparse.html)
, this is more suitable for such purposes.constants.py
(currently, some of the variables are stored inrun_config.py
)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.
The text was updated successfully, but these errors were encountered: