Skip to content

Make the Configurable surefire parser stay 100% generic with step statuses new feature

Current situation:

ConfigurableSurefireParser integrates some step statuses retrieval (from xml report), only for cucumber technology.
Thus, some code specific to cucumber has been implemented : regex and xpath + some specific way to parse the xml to retrieve each BDD step status. (all this code contains "CUCUMBER" either in variable names or in method names)

This makes the configurable surefire parsers not generic, and does not respect architecture good practices.

For now, two technologies have had step retrieval implemented:

  • Robot Framework : each step is an xml tag, and this tag has an attribute status with the value as a string. We just need an xpath to retrieves a list of String containing statuses. The method is quite similar to the status retrieval.

  • Cucumber : each step are listed in one stdout xml tag. We need an xpath to target the tag and get the string content, and then a regex to parse this string and retrieve a list of statuses.

Purpose

Make the parser truly generic.

We need to study if there is a way to generify the step statuses retrieval, one way to : - have a configuration file / or several with the same structure for all technologies - have generic methods which are able to retrieve the step statuses in ONE way, with only the information from the configuration file.

If, for all surefire-like technologies, we just need an xpath and a regex, and we always apply the same treatments to retrieve the status, we can keep the step statuses retrieval in the parser. We just need to generify what is implemented in cucumber, and extract the xpath and regex into the configuration file.

If this is not possible, we need to create a dedicated StepParser for step statuses retrieval.

After discussing it in a meeting with @mlafaix @johanHenix @llecrocq we decided to go for the second solution, and directly create a StepParser.
To do so, the configuration file should just bare an information of which parser type it uses (i.e. for cucumber : CucumberStepParser or something similar).
For the moment, we should just refactor the code, to move all the cucumber step parsing in a dedicated CucumberStepParser.
Then, if one day we need to parse step for other technologies, we will have other step parsers, or generify a StepParser if possible (two technologies -> the same parser).

Edited by Floriane Ahadi