Tibor17 commented on issue #3231:
URL:
https://github.com/apache/maven-surefire/issues/3231#issuecomment-3887971363
I decided to explain my goals from high level perspectives.
In my experience, it is quite easy for the developers to understand little
code changes.
If we are talking about a plan, this perspective cannot be used because the
goals are hard to understand from low level code changes. It is because we are
missing a big picture correlated with the goal itself.
Therefore I decided to explain a landscape of Surefire first and how the
goal fits to this big picture.
Underneath you can see an application architecture of Surefire landscape
where the left hand side is Plugin group of application components and it's own
processes, and right hand side which consists of Provider impl.
Due to this, we have two isolated runtime instances with distinguished
tasks, however they play one game together, they have to communicate somehow.
This is managed by the event-driven architecture. One can recognize commands
and events. This is an essential part of understanding the architecture in the
Surefire project.
In the lower right part of the diagram you can see two sets of events
triggered by the Provider meanwhile testing. In the top right part of the
diagram you can see mainly the commands which control the process of Test Class
Execution. Currently we rely on test class execution which is not always the
truth and we are hacking this part due to the TestNG provider sometimes
executes files and suites instead of classes. Therefore you can see two
commands in color, namely "Run Class" in red to be removed and "Run Test
Source" as a new command in green. This would provide us with a chance to
execute anything.
In the top left part of the diagram you can see corresponding commands
triggered by the plugin.
In yellow you can see the "Events Reporting" process which means that this
requires a change according to my previous email. We would benefit from this
change because the reports would do exactly the report as it is expected
without guessing the test states of the Provider. To accomplish this, we need
to employ a bit more data which would determine the status more reliably.
Namely, we would add the `UniqueID` (a distinct run of the test) and `RunID` (a
distinct ID of the run within re-run feature). Additionally, the processor of
these states should handle objects ("Test***Operation" in green) which
consistently encapsulate the test event name and particular data which is
necessary to create a consistent (and concurrently process the events) into a
report output at real time.
My goal is to give you a big picture before taking over. I understand that
making small pieces with a sequence of pull-requests would not make you
understandable why and where we are approaching to.
<img width="2061" height="981" alt="Image"
src="https://github.com/user-attachments/assets/1c5ee49c-de30-48c0-9731-fa5ab59dd1f6";
/>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
