I'm wondering something about debugging and what it means.
Currently developping a program that watches a directory and when something changes in the directory, it runs all the tests that it can find in the same directory.
So, I test what happens if you change the tests? I find that when I have 20 tests that should fail, and I change one of them to succeed, the program finds and runs all the tests and reports 20 failed tests. It doesn't use the new test, which is slightly odd.
Now, when I go through the program with a debugger, it does detect the new test!
How come the results change when using a debugger? It is the default debugger of Eclipse.
The program watches the directory using a WatchService and runs and collects the tests using JUnit.
I shall answer your question as I understand it.
The debugger in eclipse is designed for making complex applications, like GUI's or apps like your own.
The debugger allows you to change the code of a program in real time. It is designed for you to be able to edit an application, and see what your doing with it, IE changing a window size, ETC.
Each debugger run is a clean build. Try cleaning the builds of your eclipse project, this may be creating the problem, as the compiler is logging the data and expecting you to input a certain answer.
Related
I am running unit tests on java code using intelliJ and junit. The unit tests were working fine, and they still are . . . until I run in debug mode. Today, when I run in debug mode, all of a sudden, they start iterating through java files that are installed with java, I didn't write, and that I don't have permission for like the following:
This is part of the java code base that I don't have any control over and I didn't set any breakpoint here. Yet it pauses here and makes me click through it to get past it. I wouldn't care if this was only a couple of additional clicks to click through, but I have clicked like 50 times and it still keeps going through base java code that I have no control over and is not what is throwing any problem or issue.
I tried changing the settings for code coverage but that didn't seem to do anything. Is there any way to get junit to only stop at breakpoints that I, myself, specified? Any help here would be appreciated. I didn't see a similar question on Stack Overflow and the stuff on other sites is all about crafting the unit test itself.
So crazy coder (see above) was correct, but I thought I would add (after painfully trying every other alternative) that you have to go to: Run | View Breakpoints and then scroll all the way down on the left side panel (which you may not notice if you have tons of breakpoints like I did) and at the bottom there are breakpoints for Java exceptions. You need to click those OFF see below:
I am not sure if such a tool exists, so this may be moot.
Essentially, there is a JAR file containing a GUI program that is being executed in a JVM. I want to be able to see which interactions in the GUI trigger which lines of code in the source files. When I click a button on the GUI, I want to see exactly which method in the source code (or line of byte code) is triggered, and then see the flow of the program from there. I want to see values of variables, method calls, etc. Basically similar tools you would have if you were to use an IDE's debugger.
Also, decompiling the JAR and loading the source code into an IDE and using its debugger is not possible, since the JAR is launched with a Windows executable that passes in several arguments that I am unable to view. These arguments are critical to run the program.
Are there any existing tools that even come close to this?
it's probably really easy but I still don't know how to do this.
Is it possible to run a method while a program in Java is running in debug-mode in Eclipse?
While debugging, open the "Display view" to run any code you want at the position you're currently at.
See:
https://help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fviews%2Fdisplay%2Fref-display_view.htm
In debug mode, it will open a new perspective and it's going to show the workflow of your Main method, including all the methods invocations during it's execution, which variable's values has changed, everything that happen to the beginning until the end of your Main class code.
May you check this link, got a lot of usefull information.
I've tried to search for this topic but I haven't found what I'm looking for, it could be that my terminology is off however. I'm writing Java and coding in Eclipse Luna.
I currently have a program, and a set of tests related to that program that will produce a pass/fail result for each. What I'm looking for is the ability to run one of these tests and retrieve a list of the lines of code (both in the test file and the actual program) that has been executed at some point during the test. What methods can be used to accomplish this? The idea is to use that list later for fault localization if a test failed.
I'm working on a GUI program written in Java (using Swing) in Eclipse. I usually develop on Windows, and I am able to run\debug the program in Eclipse and it displays just fine. (I'm using a JUnit test to run the different windows of the GUI program).
However, I recently put Ubuntu on my machine on a second partition on my hard drive, installed Eclipse, and tried to run the JUnit test, but the GUI window appears for a second then disappears. The rest of the JUnit test runs just fine, (0 errors, 0 failures) but I can't see the GUI. Anyone know why this would happen? Thanks.
Ok, I figured it out. GUIs aren't meant to be run in JUnit tests, because as soon as the tests are completed, the program will exit, and the GUI will immediately close. For some reason, the program was staying open when I ran the JUnit test in Windows, but that's not really supposed to happen.
Because, in the current project that I'm working on, it makes more sense for me to open the GUI in a JUnit test, I implemented the following workaround: I had the method that ran the GUI simply wait until the GUI is closed before it continued to execute. To do this, I used the mechanism described here.