Hi All,
(Please make sure you can see the picture under the text or in the
attachment)
In regards to my previous email, 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.
Feel free to ask me the questions.
Please don't forget that we will have online beer appointment - Maven Apéro
on Friday late evening.
Cheers
Tibor17
[image: Maven.png]
