I am currently learning how to use JUnitCore to run some tests with my application, I think I have it all working fine as it seems to move through the debugger without any problems but I have yet to get my test to print anything to the console System.out.println(...)
Result results= JUnitCore.runClasses(test.class);
System.out.println(results.getRunCount());
When I add a breakpoint to the first line it hits it, but I have another breakpoint inside test.class that when I move to the next breakpoint it never hits, it also wont let me step into the JUnitCore.runClasses(test.class); call either... But it does return 1 for results.getRunCount()
Does anyone know if this is working for me and you are not able to hit breakpoints inside tests this way or is there a problem with JUnitCore.runClasses(test.class)?
I JUnitCore.runClasses are not supposed to print out any message, it will just run the tests.
You will need to add code that will handle any failure and therefore produces some print out.
Related
I am trying to solve the issue where one of unit tests fails only when I run all the tests in the project.
Thus I would like to come inside some common code only when my failing test is executed. I was trying to find out how to achieve it in Intellij IDEA because there is a feature of condition breakpoints, but for now I fail because don't understand how I can write this type of condition plus it seems that other possibilities don't really allow this.
Is it possible?
Put a breakpoint in the test case that fails (in the image its line 28). Put another break point(in the image its line 42) in the common-code and make that as a conditional one that is disabled till the break point in the test case is hit. To get this window, right click the breakpoint (sometimes you'll have to disable and then re-enable the suspend checkbox).
Hope it helps!
I'm not aware of an IDEA feature which lets you do this, however there are some manual steps that you can take to do this type of debugging:
Add a breakpoint to the first line of the unit test that is failing.
When this breakpoint hits, add another breakpoint in the common class you're interested in.
Alternatively, you can do this in a more automated, repeatable way by making some minor modifications to your unit test code.
Add a public static boolean field to your Unit test class which is set to false by default.
set this to true in the first line of the failing test
Use this field in your test condition. e.g. if your unit test was "ThingTest" and your field "footest" - you're condition will be "ThingTest.footest == true"
Set it to false at the end of your failing test (if you want the follow on tests to run normally)
How about declaring a boolean value, set it to false by default, and only set it to true when you test is failing.
Then you can set a condition on your in your breakpoint, to watch only when the boolean is set to true.
In IntelliJ, you add your breakpoint as per normal, then right click on it, and select View Breakpoint. Another window open, and you can enter your condition.
Hope this helps.
You have two options:
You can like you said use an conditional breakpoint if there is some state (value) in the common code, that is specific to the test you are trying to check. For example a specific string parameter.
You can put an extra breakpoint in the test you are trying to check
before the common code is called from this test. Once this breakpoint
is hit you activate the original breakpoint. You can do this
manually or using the option "Disabled until selected breakpoint is
hit" in the breakpoint dialog of the original breakpoint by
choosing your extra breakpoint in the combo box. If you use the
"automatic"-way you can even uncheck "Suspend" for the extra
breakpoint. This way it will only halt/suspend on your original breakpoint.
I have searched and found that indeed Eclipse does not support this 'direct' feature. But, Did I stil miss something? and Is it present in other IDEs?
Let me elaborate my question more -
if a statement falls under execution flow based on an expression evaluation, then why can't we force execute it? (without the execution of the expression).
For example consider this -
... if(bool returnsABoolean) {
<execute some statement>;
}
...
Can the execution of 'if' be skipped and the statement be executed as a 'next statement'? (I obviously can control the value of 'returnAsBoolean' in the Variables view; but can I not skip (in a controlloed manner) all the statements until a particular statement in the execution?)
Highlight the code you want to run and right-click/Execute or press Ctrl+U.
Alternatively to "Execute", use "Display" (Ctrl+Shift+D) or "Inspect" (Ctrl+Shift+I) to see the result.
Looks like you want the 'Display' view - in the Debug perspective, do :
Window -> ShowView -> Display.
You can enter Java statements to execute there (you have to select the bit of text each time that you want to execute)
http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fviews%2Fdisplay%2Fref-display_view.htm
Debugging allows you to run a program interactively while watching the source code and the variables during the execution.
So debugging is nothing but executing program but inspecting the elements during execution but you can not jump into something which is not there in execution.
You can use keyboard buttons F5,F6 ,F8 etc. (For Eclipse) and other Shortcuts during debugging for your convinience but you can't jump to something directly which is not in the execution sequence.
Debugging Shortcuts:
F5 Step into
F6 Step over
F8 Resume and will take you to the break point
Ctrl+Shift+B Toggle breakpoint
Ctrl+Shift+D Display Info of current statement
Ctrl+Shift+I Inspect the selected element
You can Skip some code by the use of breakpoint you can directly jump to specific point and avoid debugging of code which you believe works fine.Or you can jump out code snippet if you want to.
The question really was to set the Instruction pointer at will. This has been discussed and through url's i pasted on the comments above - this is not an eclipse feature (yet).
I need help or guidance when running two java programs and trying to read an exit error.
This'll be a little hard to explain so please forgive me if I'm not really clear.
Let's say that the chain of executing is something like this:
bat1.bat is the start, it execute myPGM.jar
myPGM.jar calls a 2nd bat: bat2.bat
bat2.bat calls an external bat, let's call it: runProcess.bat
runProcess.bat calls an external .jar and when it finish, it does echo errorlevel=%errorlevel%.
The problem is that the second .jar is failing and:
If I run all the chain: bat1.bat -> myPGM.jar -> bat2.bat -> runProcess.bat -> external.jar -> echo...
Although the external jar is failing, it always prints 0!
If I pause the execution before the runProcess.bat call, open a new cmd window and call it from there.. it prints the error correctly!
I'm really stuck with this, and probably don't have the knowledge to see where the problem is :(
My guess is that the problem can be related to the two java programs running at the same time?.. maybe the second one is like in another instance of a jvm, and that's why the bat always print errorlevel=0?
Or maybe is how I'm calling the .bat? I'm missing a parameter or something like this?
Well, reallyy really thanks!
Why do you need that? Anyway if you set the any variable in one command line you can not access it from an other.
I often make the experience, that the Console view in Eclipse gives confusing results. With most confusions (like error outputs written between some standard outputs), but with one type I can't live at all. Sometimes you have a System.out.println(); somewhere in your code and you can validate that the code before the sysout and the code after it will be executed, but still you will not see any result printed to the console. Why is that?
At the moment I saw this in a JUnit4 test (but it's not the first time).
My test looks something like this:
#Test
public void testSomething(){
//prep
...
String expected = ...
//exec
String actual = executeTestcase();
//assert
System.out.println(Formatter.doSomeformatting(actual));
Assert.assertEquals(expected, actual);
}
Perhaps you were not selecting the correct console?
In my case too I am able to use assertEquals and all similar stuff in TestCase and TestSuite,but when you want to use assert in normal program, you need to enable assertion (which is disabled by default).
To enable assertion, Select your file->Run As->Run Configurations->There select Arguments tab and in that there is text box labeled as VM Arguments. In this text box write this command: -ea.
Source: Solved same problem today on my colleagues Computer.
In my case, a previous program had not terminated and it's console was still running. I had to terminate that console manually and viola, I started getting outputs on the console again.
I'm working with the Android tutorial and I just got to the debugging section and I'm wondering what the purpose of a Breakpoint is. I can't tell just yet... is it actually stopping the app so I can be sure it runs up until that point, or can I set multiple breakpoints and use them as markers to "stop and go" from breakpoint to breakpoint checking my code?
A breakpoint is a place where the execution stops, and you can start inspecting the current situation in your debugger. This includes:
the point has actually been reached
the current values of all variables
the ability to change manually all variables
the current stacktrace - i.e. which methods were executed before the current one
the ability to add and execute arbitrary code
the ability to inspect the results of a method invocation, while not actually proceeding with the execution
In addition to that, you can manually step forward, line by line in your application. There are three options:
step into - enters a method which is invoked in the current line
step over - goes to the next line
step return - returns from the current method (to the method that invoked it)
You can set multiple breakpoints if you have multiple places where you want to do any of the above.
Generally speaking, a debugger is a very upgraded version of using System.out.println(..) or log.debug(..) all over the place in order to make sure certain conditions are present. (thanks to BalusC for this point)
You can definitely set multiple breakpoints. The questions answered by the breakpoint (alongside all of Eclipse's other debug tooling) include not only "did it get here" but also "how did it get here" (the stack trace) and "with what values" (you can observe the variables while the code is paused).