Report tab always opens in dark theme

bug-report

#1

I use webtestit with light theme (User > Preferences). When I start Webtestit and open a report, the report tab is always in dark theme (rest of the application is correctly light).
Using “Preferences > Toggle color theme” to dark and back again to light solves the problem.


#2

Hello @maxmustermann

Is this happening every time you open Ranorex Webtestit?
Have you maybe modified the user settings file that is located in the .webtestit folder ( c:\users\[username]\.webtestit)?
This may happen somehow due to the mismatch of your user settings that were modified outside Ranorex Webtestit.
Please try to make sure that the color theme is set to “light” in your settings.json file and see if that solves the issue.


#3

Yes, that happens every time I open the application. No modifications are made in that setting file.
I am still in trial mode. During last week I was prompted to login with my credentials several times. No matter why. I did not logged out before. Color theme in settings.json is correct.


#4

Ok, thank you for the information. We will take a look at this and see what is that may cause the problem. In the meantime try to switch to dark theme and then switch back to the light Theme using the preferences -->User settings -->Theme dialog.

If the report tab is still different, and annoys you too much, there is one more thing you could try. Try to delete the settings.json file from the .webtestit folder. Restarting the app will recreate the settings file, but doing you will set all your settings to default values (like wordWrap, keyboardLayout, show minimap etc., so you may want to approach this with caution!


#5

Thank you.
Is there a way to open the reports from outside Webtestit application?


#6

Yes, of course.
Just right click the report and choose Open containing folder and you can open it.


#7

Thats just the folder with plain XML files and screenshot sub folder. Is it possible to view the reports outside/without Webtestit?


#8

@maxmustermann are you talking about viewing the rendered report outside of the tool?
You can always save the report as a PDF (you’ll find that option in the toolbar of the report) or print it directly. We’re not creating those rendered files on the fly, since that would most likely pollute your project.

The basis for the reports is a JUnit report xml file. The purpose of this is to be able to easily integrate test artifacts into your CI/CD pipeline, e.g show the report results in Jenkins/TFS or whatever tool you use. Moreover some people prefer a full Reporting Tool like Allure. With JUnit as the file type, you should have the most flexibility.


#9

Hi @vsoftic,
thats exactly what I mean. I am thinking about how to make rendered reports accessible in production later on. We dont have a CI/CD pipeline or specific tool now. We just start with automated web ui testing. There is a setup with Icinga/Grafana for monitoring. I am currently trying to figure out how to go on with reporting the test results.


#10

Well as said, typically companies make use of a CI/CD pipeline, since the testcode is anyway checked into a repo and should run on predetermined actions. By doing so you’d then forward the test artifact (junit xml) and make use of it for the CI dashboard. Here’s a sample for getting setup with Jenkins and another one for TFS.

In these cases, the rendering of the report is handled by the CI tool itself, or in case of Allure, they feed their own dashboard with it. If you’re really just wanting to use our rendered report, in an automated way, we could think of adding a CLI feature to say that after a CI run, it automatically drops a PDF, alongside the JUnit file. Alternatively, there could also be a setting inside Ranorex Webtestit itself to do the same on your own runs. Since you’d have to opt-in it would be clear why files are created and space pollution might be no problem.


#11

Thanks for the explanations @vsoftic. I will have a look at the Jenkins solution.
The challenge for us is that the technical development (coding) is done by a contractor agency. The build and deploy pipeline is not accesible for our QA people. So most of testing today is made by hand on staging environments followed by acceptance testing after deployment.
With Webtestit I want to establish automated testing in our process. Thats not only a technical task. The challenge is also to consider the required organizational aspects.

Regarding your suggestion to drop a PDF: Its a good idead. But my favorite solution would be rendered HTML that our QA could access via browser.
Maybe we should think about an internal Jenkins installation just for testing and reporting solution (independend from external build and deploy process).


#12

Playing around with Jenkins doesn’t hurt for sure. Builds can be triggered in multiple way, e.g upon an external webhook or via a bot. So I definitely recommend playing around with it, even if its just for the case of reporting.

When it comes to exports in HTML the problem is that we wouldn’t be able to render a single file, since the report includes additional assets such as images and css. Thats why PDF as a self-contained document is preferred in our case.