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.
Related
I have troubles in making use of the hotswap function in Intellij IDEA Community Version. Mine is v 14.1.4.
Each time after I fired off debugging and change the java code, I have already click rebuild project and press "Yes" on confirming reload classes. Intellij reports that changed classes are reloaded, but the application outcome is the same as before. I'm just trying the simplest Java application (i.e. not in scenarios like Tomcat, applet etc) with stuffs simply like System.out.println, string concats etc. What I've changed during debug mode is just method body codes, but not the method signature/name. I can't get it.
In Eclipse I just directly change the code and press save, then it just works.
What went wrong?
(Remarks:
In fact I'm attempting to use DCEVM which makes structure change possible (e.g. change class name, method name, add methods etc), thought that it would solve the problem of the hotswap problem found in Intellij. Needless to say, it didn't work.
In eclipse, I succeed in using DCEVM and can change the method names during debugging.
I further try hotswap-agent and it still didn't work; I've come across an article saying that the IDE must JDPA-connect to the JVM thru port 5000, but no matter how I tried, Intellij console shows that it is still connecting thru a random port (51018 below):
"C:\Program Files\Java\jdk1.8.0_60\bin\java" -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:51018...."
Connected to the target VM, address: '127.0.0.1:51018', transport: 'socket'
Is it possible to force it to connect thru one specific port?
Adding the DEBUG_OPT environment variable in the Run/Debug Config doesn't work)
Found out that it is Intellij's by-design behaviour after finding one feedback from Jetbrains to an issue request:
In other words, the problem is related to how I test out the hotswapping:
public class Main {
// /*
public static String getName() {
return "James"; // <=== (2)
}
//*/
public static void main(String[] args) {
System.out.println("Hello " + getName()); // <=== (1)
}
}
As Intellij's behaviour is that "the old code is still used until the VM exits the obsolete stack frame" (a different behaviour comparing to Eclipse), if you change "Hello" to "Bye" at (1), the new code will never be executed - the new code can be executed again only when main() is called the second time, which is impossible as the application is terminated already
If it is (2) that is changed (say, replacing "James" w/ "Sean") instead of (1), during the time when the execution cursor is being stopped by a breakpoint placed at (1) (therefore haven't entered to getName() yet), and you reload the class, you will get the new code being run (printing "Sean")
DCEVM worked perfectly too, using the same way to test the hotswapping
You can also use "drop frame" in the stack trace window to make the current statement roll back to the method's beginning (except main()) - in fact it's the same behaviour in Eclipse.
I have a large project consisting of several thousand classes. Today I discovered that for some input, a different result is calculated when running with assertions enabled.
Since the assertion itself doesn't throw an AssertionError (I already have a breakpoint on that one), this means that somewhere hidden in the code is an assertion statement that has an unwanted side effect. The problem is I have no clue which of my >100 assertions is causing the problem.
Since assert is not a method but a keywordin Java, I am at a loss on how to set a breakpoint that will be hit each time assert is called.
Possible workarounds I have found:
commenting out assertions one by one and running the program to finally find the culprit.
run my test case with a code coverage tool like eclEmma to filter out some of the assertion statements.
enabling assertions only for certain packages to narrow down the number of assertions that might be the cause.
doing a search and replace (using regular expressions) to replace assert by a utility method where I can place a breakpoint.
Nonetheless, I would like to know if anyone knows of a way to break on assert, even if the condition evaluates to true.
Goto Run->Add Java Exception Breakpoint
Type 'AssertionError' in search box
Choose java.lang.AssertionError and OK
Now Eclipse will suspend on assert
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.
I am new to JUnit and I got a sample java project in which I need to write unit tests for all the methods.
Unfortunately the code is poorly designed and some of the methods are done from the UI. Furthermore, some of the methods pop up a messagebox and do not return a return value.
I have two questions: First, without modifying the existing code, is there a way I can suppress the message boxes and not press enter every time I run the unit tests?
Second question: can a test function expect a message box and assert failure\success upon it's string content?
I appreciate any help, I know the best solution is to fix the code itself - separate the BusinessLogic completely from the UI and to test expected result, or even if message boxes are somehow mandatory use modal message boxes (like humble dialog boxes) but unfortunately I am not allowed to change anything in the code.
Thanks :)
Nili
There are all sorts of ways you could get started if only you were allowed to edit the code, so my first approach would be to see if you can get this restriction relaxed, and to read Working Effectively With Legacy Code.
Failing that you could try using a GUI testing framework like FEST-Swing to check the contents of the message boxes are as expected.
Not allowed to change the code, you say? First thought it to have a look at JMockit which really opens up a lot of possibilities when you are severely constrained by code that was not written with much concern about how it should be tested. It should enable you to, without modifying any code, substitute your preferred implementation of bothersome parts while your test is running--so only in the context of testing would you have altered the test subject (be careful to write a meaningful test!) or its dependencies. Other mock object frameworks can be useful, too, but the investment to learn JMockit is really time well-spent.
unfortunately I am not allowed to change anything in the code.
There's all sorts of stuff on Google about how to automate Swing testing with JUnit. Unfortunately, there's no way to get around this problem when testing.
I have a Java program which its main method (in the main class) expects command line arguments. The program is also concurrent (uses threads and stuff).
I want to do massive refactoring to the program. Before I start refactoring I would like to create a test suit for the main method. I would like to test the main method with different cmd line arguments. I'll want to run these tests automatically after each refactoring step I make. How do I create a test which passes cmd line arguments?
I cannot use JUnit because as far as I know it doesn't work well with concurrent programs. I'm also not sure if you can pass cmd line arguments with JUnit.
I'm using eclipse.
Take a look at multithreadedtc. http://code.google.com/p/multithreadedtc/
Consider using JMeter. With JUnit sampler you can make concurrent JUnit tests easily, and see the result. See this question for more details.
I'm not familiar with the various automation tools available specifically for multi-threading, so I won't comment on them. But on simple yet effective option is to log key events from the running program to a CSV file. You could log the final result (if it is a calculation type program) or log out at every instance in the program where some key state is changed or event occurs. Because it's a multi-threaded app you would have to pay attention to comparing the sequence of logged data, if you can not guarantee the relative ordering of the key events you expect to see then compare output using key-value type results. Either way, the idea would be to create test data files which you can use for automated comparison when back testing.
Awaitility can also be useful to help you write deterministic unit tests. It allows you to wait until some state somewhere in your system is updated. For example:
await().untilCall( to(myService).myMethod(), greaterThan(3) );
or
await().atMost(5,SECONDS).until(fieldIn(myObject).ofType(int.class), equalTo(1));
It also has Scala and Groovy support.
await until { something() > 4 } // Scala example