HolQue
commented
1 year ago I have to admit: This is in opposite to what I wrote in
https://github.com/test-fullautomation/robotframework-robotlog2db/issues/28
(2) In my opinion it makes no sense to let the RobotFramework_TestsuitesManagement initialize web application related parameters.
But after thinking about this again and again, now my feeling is, that the RobotFramework_TestsuitesManagement is the better place ;-)
ngoan1608
Both database applications RobotLog2DB and PyTestLog2DB provide mechanisms to add values missing in the XML result log files (by config file and by command line). This looks a little bit like trying to repair a result - instead of solving the root cause.
For me it's like that: A test runs and produces results. And the test must know, under which conditions this happens. Results and conditions must be present in the log files. Doing further computations with these log files is under the responsibility of complete different applications (here the database applications). They have nothing to do with the test execution. Therefore the database applications must not be allowed to do any interpretation of the test results. But allowing them to define things like variant names or version numbers is allowing them to interprete the test results. This is not OK.
What happens if someone is in hurry, quickly downloads a new last minute version and forgets to adapt the database application configuration files? On web page the test results will be put into the wrong bag.
No matter where values can be defined: There must be a user who does this. And therefore it is better to tell this user: Do this in your test! And not in any other configuration file that belongs to a complete different tool chain. In case of any missing value the database application should throw an error. No default values any more.
We should think about better solutions for supporting user to define all required values already inside tests. It should be possible to tell them: In case you do not only want to have your test results logged, but also want to have your test results displayed on a web application, then you have to do further preparations, because now further values are mandatory.
Another advantage is to have these informations present in the test log files also. Configuration parameters of the database applications are not present in the test log files.
Maybe a solution is to move the configuration file mechanism from the database applications to the RobotFramework_TestsuitesManagement - because this application is also prepared to handle configuration files in JSON format already. A further configuration would only be an extension here.