On 04/02/2025 21:08, Dean Marx wrote:
Hi Luca,
I saw in the meeting minutes that the main purpose of this series is
to implement the separation of concern principle better in DTS. Just
wondering, what parts of the current framework did you think needed to
be separated and why? I'm taking an OOP class this semester and we
just started talking in depth about separation of concerns, so if you
wouldn't mind I'd be interested in your thought process. Working on a
review for the series currently as well, should be done relatively
soon.
Thanks,
Dean
Hi Dean,
For starters all the major logic was held within the `runner.py` file,
which is not ideal. When some logic touches the same object too often,
maybe its an indicator that it actually belongs to that class instead.
For example, the test suite and cases are configured within the
configuration. Anything configuration should be kept within the
configuration, the runner should assume that the configuration is final
and is ready to be fed to the classes. For this reason, I've moved the
test suite and cases filtering logic there. Test runs are a whole
concept on their own, and they have their own logic. For this reason it
is a better idea to have them individually in their own dedicated class
where they can control themselves. As opposed to having a runner.py
basically dealing with every part of the framework in the same place. If
you were to make a graph with all the linked classes to runner.py, I am
sure it'd look like spaghetti. We don't want that. We want a hierarical
and structured approach. Separation of concerns will aid this by keeping
things where they belong, minimising import/export. This will also help
with circular import issues.
Hope this provides some insight!
Luca
