Hi Folks, maybe one of you has an idea how I can resolve this problem.
Hi Folks, maybe one of you has an idea how I can resolve this problem.
I'm running Unit tests with the DUnit GUI test runner that ships with XE2. The suite consists of some lengthy tests which are created from parameter files. While these tests are running I like to do some "work".
My problem now is that the GUI test runner steals the focus from my currently active application every few seconds, when one of the tests is finished. So I can't really do much while the tests are running.
I know that I can use the console test runner which won't steal my focus, but especially when I try to narrow down a problem, I want to interactively check and re-run single tests without having to sit through the entire suite.
Has anyone else encountered this problem too? And maybe even found a solution? I haven't understood when and why this happens. Commenting out Application.Processmessages or fiddling with the runners options doesn't help.
Cheers & thanks
I'm running Unit tests with the DUnit GUI test runner that ships with XE2. The suite consists of some lengthy tests which are created from parameter files. While these tests are running I like to do some "work".
My problem now is that the GUI test runner steals the focus from my currently active application every few seconds, when one of the tests is finished. So I can't really do much while the tests are running.
I know that I can use the console test runner which won't steal my focus, but especially when I try to narrow down a problem, I want to interactively check and re-run single tests without having to sit through the entire suite.
Has anyone else encountered this problem too? And maybe even found a solution? I haven't understood when and why this happens. Commenting out Application.Processmessages or fiddling with the runners options doesn't help.
Cheers & thanks
I cannot reproduce this on Windows 7 (tested with XE and XE4)
ReplyDeleteTry turning off runtime themes for the DUnit application. Even if it does not solve that problem you will notice tests running much faster.
Stefan Glienke Thanks for the hints.
ReplyDeleteI forgot to say one thing. This only happens when I run the test suite from the IDE. If I just compile and run it from the windows explorer, the application doesn't steal my focus.
It flashes a lot. Looks like it repaints itself fully all the time.
I'm not using runtime themes (to my knowledge) :)
I tried to comment out many of the update routines in the GUI test runner, just to narrow it down, but I haven't found the right one yet.
I miss a logging interface in DUnit, where the test app can log progress / parameter / validation info.
ReplyDeleteLars Fosdal I'm using a slightly modified version of "FinalBuilder.XmlTestRunner.pas" (don't remember from where I downloaded it. Many hits, probably the one from the delphi spring framework) for the console test runner plus my own xsl+css to display the results. Do you mean something like this?
ReplyDeleteNot quite as sophisticated. Just a simple log window in the test UI.
ReplyDeleteLars Fosdal DUnit has that. The method you are looking for is called Status()
ReplyDeleteo.0 - Since when!?
ReplyDeleteDon't know. I just tried status() for the first time. But it's only visible in the bottom error box during one test case. The next test clears the error box. Maybe you have to implement your own IStatusListener.
ReplyDeleteLars Fosdal Since Fri Dec 14 23:15:21 2001 :)
ReplyDeleteAs Lübbe points out, it doesn't log, so I probably dismissed it as not useful.
ReplyDeleteLearning a bit more about DUnit right now, but I'm still stuck with my original problem. There's a timer in the GUI test runner, but this doesn't seem to cause the focus steal.
ReplyDeleteI can reproduce the problem to 100% if I run the GUI test runner from the IDE with debugger. It'll steal the focus from any application, including XE2. If I run it without debugger, the test runner is happily updating itself, and it doesn't steal the focus.
So my current workaround is to run it without debugger, but I'd still like to know why this happens.
As some tests might cause exceptions to raise (not speaking of failures) to me it never is a good idea to run it inside the debugger as it stops at every exception.
ReplyDeleteI also cannot reproduce it with running inside the debugger. It might actually be related to your test code.
Yes, but while working on my test cases and application it's more than natural for me to hit F9, see which tests fail, select those, set a breakpoint re-run them and investigate.
ReplyDeleteIf everything is fine, I need neither GUI nor debugger.
Graeme Geldenhuys Thanks. I didn'r know that it was a drop-in replacement. I'll give it a go.
ReplyDeleteGraeme Geldenhuys - Already have plenty of logging (file, debugout, database, with or without callstack, etc), just no UI in DUnit to present it in the relevant context.
ReplyDeleteI wonder if a unit testing framework should provide logging at all. Sedation of concern. Any opinions on that?
ReplyDeleteJeroen Wiert Pluimers Separation ;) The unit test framework might provide a logging interface or take one (the problem there is that there exists no standard logging interface that it might use so defining its own might be the way).
ReplyDeleteStefan Glienke not sure of that was me or the autocorrect. Let's blame myself for a change (: I agree about your interface points. Do JUnit or NUnit have such interfaces?
ReplyDeleteFirst I want to ask what logging are we talking about here? Logging into the test gui itself? Logging to some external component. In both cases the logging code most likely will sit in your test code so you can decide what kind of logging you want to use - you can also abstract that into some TLoggingTestCase or something like that which extends the TTestCase by some logging methods. Imo this is a simple case of composition of 2 things (1. testing framework, 2. logging component)
ReplyDelete