How to use toString method of junit.framework.TestCase class

There is many correct answers here, but I would like to add my version too. This is based on Assertj.

import static org.assertj.core.api.Assertions.assertThat;

public class TestClass {

    public void test() {
        // do the actual test
        assertThat(actualObject)
            .isEqualToComparingFieldByFieldRecursively(expectedObject);
    }
}

UPDATE: In assertj v3.13.2 this method is deprecated as pointed out by Woodz in comment. Current recommendation is

public class TestClass {

    public void test() {
        // do the actual test
        assertThat(actualObject)
            .usingRecursiveComparison()
            .isEqualTo(expectedObject);
    }

}

By default Maven uses the following naming conventions when looking for tests to run:

• Test*
• *Test
• *Tests (has been added in Maven Surefire Plugin 2.20)
• *TestCase

If your test class doesn't follow these conventions you should rename it or configure Maven Surefire Plugin to use another pattern for test classes.

You've imported the types, but not used a static import to make the members available without qualification. If you use:

import static org.junit.Assert.*;

then that should statically import all the static methods in the Assert class, so you can write assertTrue instead of Assert.assertTrue.

Note that presumably Assert itself has nested types, otherwise I'd have expected your "normal" import to fail.

Right-click on the package in the package explorer and select 'Run as' and 'Unit-Test'.

1. Consider using ExpectedException instead of @Test(expected.... This is because if for example you expect a NullPointerException and your test throws this exception in your setup (before calling the method under test) your test will pass. With ExpectedException you put the expect immediately before the call to the method under test so there is no chance of this. Also, ExpectedException allows you to test the exception message which is helpful if you have two different IllegalArgumentExceptions that might be thrown and you need to check for the correct one.

2. Consider isolating your method under test from the setup and verify, this will ease in test review and maintenance. This is especially true when methods on the class under test are invoked as part of setup which can confuse which is the method under test. I use the following format:

   public void test() {
      //setup
      ...
   
      // test (usually only one line of code in this block)
      ...
   
      //verify
      ...
   }
   

3. Books to look at: Clean Code, JUnit In Action, Test Driven Development By Example

   Clean Code has an excellent section on testing

4. Most example I have seen (including what Eclipse autogenerates) have the method under test in the title of the test. This facilitates review and maintenance. For example: testOfComponents_nullCase. Your example is the first I have seen that uses the Enclosed to group methods by method under test, which is really nice. However, it adds some overhead as @Before and @After do not get shared between enclosed test classes.

5. I have not started using it, but Guava has a test library: guava-testlib. I have not had a chance to play with it but it seems to have some cool stuff. For example: NullPointerTest is quote:

• A test utility that verifies that your methods throw {@link * NullPointerException} or {@link UnsupportedOperationException} whenever any * of their parameters are null. To use it, you must first provide valid default * values for the parameter types used by the class.

Review: I realize the test above was just an example but since a constructive review might be helpful, here you go.

1. In testing getComponents, test the empty list case as well. Also, use IsIterableContainingInOrder.

2. In testing of ofComponents, it seems that it would make sense to call getComponents or toString to validate that it properly handled the various non-error cases. There should be a test where no argument is passed to ofComponents. I see that this is done with ofComponents( new String[]{}) but why not just do ofComponents()? Need a test where null is one of the values passed: ofComponents("blah", null, "blah2") since this will throw an NPE.

3. In testing ROOT, as has been pointed out before, I suggest calling ROOT.getComponents once and doing all three verifications on it. Also, ItIterableContainingInOrder does all three of not empty, size and contains. The is in the tests is extraineous (although it is linguistic) and I feel is not worth having (IMHO).

4. In testing toString, I feel it is very helpful to isolate the method under test. I would have written toStringIsSlashSeparatedPathOfComponents as follows. Notice that I do not use the constant from the class under test. This is because IMHO, ANY functional change to the class under test should cause the test to fail.

   @Test     
   public void toStringIsSlashSeparatedPathOfComponents() {       
      //setup 
      String[] components = { "Test1", "Test2", "Test3" };       
      String expectedPath =  "/" + Joiner.on("/").join(components);   
      MyPath path = MyPath.ofComponents(components)
   
      // test
      String value = path.toStrign();
   
      // verify
      assertThat(value, equalTo(expectedPath));   
   } 
   

5. Enclosed will not run any unit test that is not in an inner class. Therefore testPathCreationFromComponents would not be run.

Finally, use Test Driven Development. This will ensure that your tests are passing for the right reason and will fail as expected.

The problem was with a library I was using. Since I had the library project loaded into IntelliJ, when I ran the tests manually, the library code was being used. But Maven used the library from the .m2 repository, which didn't have the .jar up to date. This out of date jar had something that was causing the creation of the table EngineConfigs to fail. In case anyone is facing the same problem, a useful trick is to remove the ":mem" from the database connection URL and inspect the *.trace.db file that is generated when running the tests. That trace file will give you information about the real underlying issue.

While there is no only right way, the usual approach is to keep unit tests in the same project.

You can create a second source folder (like test), where you put your test classes into the same packages as the classes under test. This also allows you to test package-private classes while not flooding your main source packages with test classes.

Your source folder/package structure would then look like this:

-sources
   -main
       -my.package
             -MyClass.java
   -test
       -my.package
             -MyClassTest.java

You can then configure your build to not include the test source folder when packing the JAR.

Keep in mind the difference between unit testing and integration testing.

Unit tests should be testing code without any outside dependencies. These dependencies are mocked using a framework like, for example, JMock.

Integration tests are important too but the major drawback of them is that they take a long time to run. You can run thousands of true unit tests in a couple of seconds, but it's not the same with integration tests.

Depending on the size of your project/development team you might want to prioritize true unit tests over integration tests. Both style of tests are important but if you are pressed for resources, just going with Unit testing may be a better idea.

I wrote an application by myself that unit tested the Web (with Spring MVC this is easy) and Service layers, as well as domain objects. But I left the DAO alone because I didn't want to write a bunch of slow integration tests. If I had more people on staff I would have gone with integration tests as well, but in this case I didn't feel the time spent would be worth it.

Just ran into this post trying to fix it for myself. Gave me just enough information to work it out.

You can give the compiler just enough to persuade it to compile by casting the return value from hasItems to a (raw) Matcher, eg:

ArrayList<Integer> actual = new ArrayList<Integer>();
ArrayList<Integer> expected = new ArrayList<Integer>();
actual.add(1);
expected.add(2);
assertThat(actual, (Matcher) hasItems(expected));

Just in case anybody else is still suffering ...

Edit to add: In spite of the up votes, this answer is wrong, as Arend points out below. The correct answer is to turn the expected into an array of Integers, as hamcrest is expecting:

    ArrayList<Integer> actual = new ArrayList<Integer>();
    ArrayList<Integer> expected = new ArrayList<Integer>();
    actual.add(1);
    expected.add(2);
    assertThat(actual, hasItems(expected.toArray(new Integer[expected.size()])));