The "right" solution is to call the asynchronous API and then call wait(). The thread should call notify() when it is done. The test thread will continue and validate the results. In practice I cannot modify the background thread and add notify() there. It is too deep into the application I am working on. Moreover I do not want to modify production code to help myself writing unit tests. So I decided to use "simple" solution: each my test calls the asynchronous API, then invokes Thread.sleep(100L), then verifies the results. 100 milliseconds are enough for the asynchronous task to complete.
But when I am debugging my code that is invoked by background thread I do not want the test to be terminated. Actually I want my test to sleep infinitely. I changed the parameter of sleep() many times and thought that actually I need automatic mechanism that understands that code is being debugged now and chooses sleep period automatically. I checked system properties and did not see any difference when test is running normally or being debugged.
Other idea was to try JMX. Really, Runtime MBean can help here:
ManagementFactory.getRuntimeMXBean().getInputArguments(). According to javadoc this method:
Returns the input arguments passed to the Java virtual machinewhich does not include the arguments to the main method.
So this is exactly what I need!
Here are 2 examples of return value of this method:
- Running program with remote debugger:
[-Xdebug, -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n]
- Debugging program under eclipse:
The following utility method returns true if program is running under debugger and false otherwise:
public static boolean isDebugging() {
Pattern p = Pattern.compile("-Xdebubg|jdwp");
for (String arg : ManagementFactory.getRuntimeMXBean().getInputArguments()) {
if (p.matcher(arg).find()) {
return true;
}
}
return false;
}
I hope that regular expression I used here is general enough to support other IDEs.
Now we can use this code when we need different behavior of our code being executed normally or being debugged.
No comments:
Post a Comment