I wanted to know do we have an option to get a consolidated HTML report after running the different test cases under 1 package. Curently when we run the cases using mvn gatling:test command it executes sequentially all the cases and generate separate html reports .
It would be a great gesture if someone could help or suggest .Thanks in advance
There is no one solution fit all use cases for this “consolidation”.
Should the value be aggregated as if all Simulations started at the same time? One after the other (which order?) How much time between them? What about conflicting request name? group name? scenario name?
Thanks @sbrevet for your prompt reply.Im aware of the multiple scenarios under 1 simulation, but i’m thinking on microservice architecture framework level where having all the scenarios under 1 cases doesnt make sense and not feasible as well.
Moreover if gatling is producing different reports for individual simulations, there can be a provision provided to concatenate all the reports and show a summary of the reports under 1 file , though configs and load might be different irrespective of the duration for which they were triggered . Once run is complete it can just summarise under details tab .Let me know if thjis makes sense to you .
So, I bet the “consolidated” HTML reports doesn’t make sense either
I doubt it.
If you can create a Simulation right now, you can extract the scenario of this microservice.
In another component (module, jar, etc) you might aggregate the different scenarios for the different cases, so you can build the Simulation that consolidates your wanted reports.
If you are talking about things as httpprotocol, baseUrl, etc. They are only base configuration and each injection profile may use their own, or the request may override it.
If you are talking about shared global variables, as they will lie in their own class and their own package, the variables won’t collide.
If you are talking about external configuration (system properties, environment variables), it is about the custom code and we can think about prefix or other way to distinguish them.
As stated in my previous message, there is no solution that fit all use cases. Without knowing the particular use case, no one will be able to “consolidate” for your needs.
Even the stored percentile may be different (as it is a configuration of the simulation), you can’t compare apples and oranges.