I'm trying to test existing software and I'm running into an issue; if, during a junit test suite, I close a gui window, the whole test suite just ends. No errors, failures, or successes. It definitely ends too, because it closes all other windows as well, and terminates the thread.
I'm not using junit to the test the GUI - that's more of a system test obviously, and I'm using GUI automation software for that. However, in order to test a method in one of the classes in the software, I have to have stuff going on with the gui. At the end of the tests, I need to close the windows or they will remain open and will actually interfere with the other tests (it's networked software). However, as said, sending an onclosing event to any window immediately ends the test suite.
I became curious about the whole thing and slowly came to realize, to my horror, that even in normal execution, if I close a window, it's not handled within the software, it just magically stops executing! The main driver's loop doesn't even have any exit condition whatsoever, just while(true) with no breaks! My thinking is this must be related to why everything just stops when I close a window during the tests.
Anyways, I still don't fully understand what's happening, so if someone could fill me in, that would be great. But my main question is how can I fix/ get around this issue and close windows without killing the whole test suite.
Note: I can't change the behavior of the software. (As you may have guessed, this is for a class)
Sounds like the window close is calling System.exit(). If you have the ability to remove that, you could do so. If you don't, you could install a SecurityManager that prevents the call during testing. Example here: Preventing System.exit() from API
Related
Testing a multithreaded application with JUnit5, the automated tests run just fine.
But in manual debugging, the environment misbehaves, and I would like to know how to get it to act as it should.
IntelliJ (using the Java VM + its debugger) has two general options to suspend on breakpoints: either "All" = all threads, or "Thread" = the current thread only.
(Which thread is "the current thread" may be unclear and causing issues, but that's been discussed separately, see other issues here on stackOverflow.)
Wanted behaviour:
a breakpoint to suspend a specific thread, and the JUnit test environment, which is part of the IDE debugging.
Actual behaviour:
either all threads are suspended, even those which should be running
or only a single thread is suspended, and JUnit #AfterEach/#AfterAll annotations kill the resources currently debugged, terminating the threads that should be running, etc.
How to achieve the Wanted behaviour?
(Environment: AdoptOpenJDK8, AdoptOpenJDK11 in Java 9 mode, IntelliJ 2020.3, JUnit-Jupiter 5.7.0)
You can use two breakpoints. The one you're really interested in and another one in your unit test (somewhere between calling the code under test and cleaning up). Set both to only suspend the current thread.
I'm using Java 11, JNA with a DLL on Windows 10 64-bit, JUnit 4.12, Eclipse 20190314-1200, (aka 4.11.0). This is a gradle-based project, but I ran out of tags.
Quite a bit of that may not be relevant, but context never hurts, right?
While running any unit test that touches the DLL in question, the test silently fails, almost immediately. Almost. When I try to step into the goings on, I land in Structure.autoWrite() (the member function, not the static one), and when I step out, poof. The test ends. The call stack looks remarkably like I called autoWrite() directly, though it is actually a native method call. Eclipse's JUnit UI continues to show that test as if it were still running (little blue triangle overlay on the icon), but the tests all stop. JUnit doesn't even try to run any further tests.
I haven't found any logs. Standard out simply shows my last output (the path JNA uses to find DLLs). I got nuthin'.
Does anyone know of a relevant log file (not in user.name/appdata/local/temp, I checked quite thoroughly)? Some configuration I can tweak for more verbose output? Where I can find the JVM exit code maybe? Anything?
The DLL in question wasn't installed properly (by me), and when I first call an initializer function, it logged an error (in an unexpected corner of my hard drive) and called exit(), which is just rude.
Your DLL shouldn't end my program's process. At least it didn't cause Eclipse to shut down. That would have been... vexing.
And that was the last hurdle between me and a full suite of passing unit tests. Whew.
Upward and onward!
I am using IntelliJ IDEA 12.1.6 on (64-bit) Windows 7 Enterprise (I've also seen this same problem with IDEA 11, though not as often). I am running it under Java 7 (1.7.45).
When I run a program in the IDE, under the debugger (local debugging), everything is fine until I hit a breakpoint (these are plain old on-a-specific-line breakpoints, not method breakpoints or exception breakpoints). Once the breakpoint is hit, virtually all the time (though not always) my entire machine slows to a near halt. All keyboard operations (not just in IDEA) slow way down (they eventually do get processed so the events are buffered, not lost). Same for window operations (drag, minimize, raise, lower). Once the program resumes from the breakpoint everything goes completely back to normal until the next time a breakpoint is hit.
This is obviously really annoying as it makes debugging essentially impossible.
I've had Task Manager up and don't see anything strange. The CPU is not pegged, memory isn't maxed out, etc. My hard drive light isn't on.
Any ideas on what's going on and (more importantly) how to fix it?
It's hard to say what the problem is, but here are some things that might help:
Invalidate caches as described here--though be aware of the consequences.
Make sure you have only enabled those plugins you are actually using or likely to use.
Try to find if all breakpoints have the same problem or if, for example, you only have issues with Java breakpoints but not JavaScript ones. If that happens, it could give you a clue.
Well, it looks like my specific problem is IE-related.
The program I am debugging is the server-side of a webapp. (Sadly it is IE-only due to some weird stuff in the Ajax it is using -- I'm not responsible for that).
I have been setting my breakpoints, running the server under the debugger, and then doing stuff with the webapp in IE, which ultimately causes breakpoints to be hit. When a breakpoint is hit and I am single-stepping, everything remains OK if I do not use the keyboard at all. If I click on the various single-step icons or select the single-step actions via mouse from IDEA's "Run" menu everything keeps working. But the moment I use F8 to single-step, or hit a key in any other problem (like in a mail program) the freeze happens.
It finally occurred to me (shame on me) to run IE on another computer while running the server in the IDEA debugger on my main computer. When I do that, everything is fine and I can use the keyboard in any application, as much as I want to, and the freeze does not happen.
So the problem seems to be IE causing weirdness when it has sent a request and is waiting for a response from the server. Still, there does seem to be some interaction with IDEA because when I run IE on a separate computer and hit a breakpoint on my computer, I can use the keyboard all I want on the computer where I am running IE without any problems at all.
I have written tests for my windows based application in TestNG. Sometimes my tests will result in BSOD of windows, so the test will run waiting for the Windows to be up till timeout and fail.
I have written a Listener for BSOD detection and handling, so that whenever the test starts the BSOD detector will start as listener and handle if the BSOD occurs. But still I have no way to notify my test that it has to halt. It still continues to execute till timeout.
How can solve this problem? Is there a way to notify the test to terminate it from Listener?
I think you may be out of luck.
The discussion at https://groups.google.com/forum/#!topic/testng-users/BkIQeI0l0lc clearly indicates that, as of August 2012 there was no way to stop a running test suite.
That combined with a much older post (https://groups.google.com/forum/#!topic/testng-users/FhC3rqs1yDM) from February 2010 suggests it has been a shortcoming of TestNG for a while.
The current TestNG documentation does not describe any methods for stopping the suite.
From what I can see in the source code (although I have not traced through all paths) at https://github.com/cbeust/testng/blob/master/src/main/java/org/testng/TestNG.java, it simply creates new tasks for each test and runs them, providing no way to break early.
Perhaps you could modify your tests to have access to some flag that indicates if subsequent tests should be skipped (triggered by, e.g., the BSOD detector). Then all of your subsequent tests are responsible for indicating themselves as skipped if this flag is set. It might not be ideal, but one way to think about it is: Any test should be skipped if a BSOD (or other terminal event) was detected prior to that test.
You could request this feature on the TestNG Google Group (linked above). If you are so inclined, you could also perhaps customize the TestNG source.
I am running a Java Program in command prompt
The normal course is after successfully executing the program it comes back to prompt .. what are the possible reasons it will not come back to prompt after successfully executing the program
why is it not coming back to prompt after execution
usually it comes back but sometimes it doesn't...
This sounds like a race condition. Something in your application's shutdown sequence is non-deterministic, and it works or does not work depending on various platform specific (and possibly external) factors. There is probably no point figuring out what those factors are (or might be), since it won't help you fix the problem.
Only difference is in RAM hard disk capacity mine is slower.. Can it be possible reason?
These could be factors, but they are not the cause of the problem. So focus on figuring out what makes your application non-deterministic.
As others have said, without more information (and relevant code) we can only guess.
When the application has failed to shut down, get it to give you a thread dump. Or try shutting it down while it is attached to a debugger. These may allow you to get some clues as to what is going wrong.
Finally, the brute force solution is simply to have the main method (or whatever) call System.exit(0) on its way out. But beware of the possibility of files not being flushed, etc if you do that.
Because it's not finishing. If it's sometimes happening and sometimes not, my instinct is that you have some sort of race condition. Probably one of your cleanup steps is hanging if another action has or hasn't been taken.
Without source code this will be hard to debug.
There could be an active thread still running which is not in "daemon" mode. For example, if you have a Swing GUI and all of the frames are closed the Event Dispatch thread is still active so the JVM will not exit.