Page 1 of 1

Show current test execution status

Posted: Wed Nov 12, 2014 12:52 pm
by sravanimandadi
Can any one suggest for a possibility that allows me to show some text that says what exactly is happening in the current situation on the screen (a tool tip or a blink message) while the recording is being executed?

Re: Request..

Posted: Wed Nov 12, 2014 3:47 pm
by krstcs
Why do you need to see that information during the run? The report will show you what happened.

Automation is supposed to allow you to run the tests without having to have a human watching the test run. If you are having a human sit and watch the test, you may want to reconsider what you are using automation for and possibly work on automating the validation.

Re: Request..

Posted: Wed Dec 03, 2014 4:08 pm
by keith
@sravanimandadi,
This is similar to a recent question I asked as well. See link below.
Can you not see the console output running when you run your tests via Ranorex studio? I see a console output that I just stick on my 2nd screen. Also, I believe you can adjust the NLog.config to log according to your needs and monitor in other free tools.

My Question
http://www.ranorex.com/forum/monitor-ra ... t7178.html

NLog
http://nlog-project.org/

NLog Viewers
https://github.com/nlog/nlog/wiki/Tools

@krstcs
That would be great if we knew are tests would always work. I find that the easiest way to "test" my test while they are still under development is to run it and do something else in the meantime. Also, if you have a long run it is quite normal to want to have a running status. I keep an eye on the console for red. Once my script is ready for prime time I can check it in. Do you do it differently?

Re: Request..

Posted: Wed Dec 03, 2014 6:00 pm
by odklizec
Hi Keith,

I think the best way to achieve what you want is to integrate Ranorex with a continuous integration tool (Jenkins, Bamboo,...). You can easily configure it to inform you or anyone else in the team in case of failure. But it's only a small piece of CI cake. You can do much more with CI. I personally found the CI approach invaluable. Anyone who is serious about QA should consider it.

Re: Request..

Posted: Wed Dec 03, 2014 6:51 pm
by krstcs
On top of what Odklizec said, I would also highly recommend creating your recording and user-code modules to be as small as possible.

If you need to click the OK button, make a module that does just that. Call it "Click_OKButton" so everyone knows exactly what it does. Then, test it by itself to make sure it works. Drop it in the test case where you need it, and the only thing you will need to worry about is timing or SUT errors. Those can be easily handled through various mechanisms. This will make it easier to both maintain the tests and to know what they are doing.

Long test modules should be used only when you need very complex logic. Use small modules with Module Groups for everything that is just a group of actions that need to run together all the time. Remember you can make hundreds of groups that do very similar things and name them accordingly. This will allow you to make test case much easier and everyone will know what is going on without having to dig through modules and code.


This also would benefit you specifically because it will let you test small sections of code by themselves without running huge modules, and you can be confident that they work. It also make re-use much easier, especially if you make the small modules as generic as possible.