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.

  • No labels