How to use isAnyExceptionExpected method of org.junit.rules.ExpectedException class

As duffymo hinted at, the Spring TestContext Framework (TCF) assumes that string locations are in the classpath by default. For details, see the JavaDoc for ContextConfiguration.

Note, however, that you can also specify resources in the file system with either an absolute or relative path using Spring's resource abstraction (i.e., by using the "file:" prefix). You can find details on that in the JavaDoc for the modifyLocations() method in Spring's AbstractContextLoader.

So for example, if your XML configuration file is located in "src/main/webapp/WEB-INF/spring-config.xml" in your project folder, you could specify the location as a relative file system path as follows:

@ContextConfiguration("file:src/main/webapp/WEB-INF/spring-config.xml")

As an alternative, you could store your Spring configuration files in the classpath (e.g., src/main/resources) and then reference them via the classpath in your Spring MVC configuration -- for example:

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>classpath:/spring-config.xml</param-value>
</context-param>

<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

With this approach, your test configuration would simply look like this (note the leading slash that denotes that the resource is in the root of the classpath):

@ContextConfiguration("/spring-config.xml")

You might also find the Context configuration with XML resources section of the reference manual useful.

Regards,

Sam

(author of the Spring TestContext Framework)

You can try @Rule annotation. Here is the example from the docs:

public static class UsesExternalResource {
    Server myServer = new Server();

    @Rule public ExternalResource resource = new ExternalResource() {
        @Override
        protected void before() throws Throwable {
            myServer.connect();
        };

        @Override
        protected void after() {
            myServer.disconnect();
        };
    };

    @Test public void testFoo() {
        new Client().run(myServer);
    }
}

You just need to create FileResource class extending ExternalResource.

Full Example

import static org.junit.Assert.*;

import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.ExternalResource;

public class TestSomething
{
    @Rule
    public ResourceFile res = new ResourceFile("/res.txt");

    @Test
    public void test() throws Exception
    {
        assertTrue(res.getContent().length() > 0);
        assertTrue(res.getFile().exists());
    }
}

import java.io.BufferedReader;
import java.io.File;
import java.io.FileOutputStream;
import java.io.FileReader;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.nio.charset.Charset;

import org.junit.rules.ExternalResource;

public class ResourceFile extends ExternalResource
{
    String res;
    File file = null;
    InputStream stream;

    public ResourceFile(String res)
    {
        this.res = res;
    }

    public File getFile() throws IOException
    {
        if (file == null)
        {
            createFile();
        }
        return file;
    }

    public InputStream getInputStream()
    {
        return stream;
    }

    public InputStream createInputStream()
    {
        return getClass().getResourceAsStream(res);
    }

    public String getContent() throws IOException
    {
        return getContent("utf-8");
    }

    public String getContent(String charSet) throws IOException
    {
        InputStreamReader reader = new InputStreamReader(createInputStream(),
            Charset.forName(charSet));
        char[] tmp = new char[4096];
        StringBuilder b = new StringBuilder();
        try
        {
            while (true)
            {
                int len = reader.read(tmp);
                if (len < 0)
                {
                    break;
                }
                b.append(tmp, 0, len);
            }
            reader.close();
        }
        finally
        {
            reader.close();
        }
        return b.toString();
    }

    @Override
    protected void before() throws Throwable
    {
        super.before();
        stream = getClass().getResourceAsStream(res);
    }

    @Override
    protected void after()
    {
        try
        {
            stream.close();
        }
        catch (IOException e)
        {
            // ignore
        }
        if (file != null)
        {
            file.delete();
        }
        super.after();
    }

    private void createFile() throws IOException
    {
        file = new File(".",res);
        InputStream stream = getClass().getResourceAsStream(res);
        try
        {
            file.createNewFile();
            FileOutputStream ostream = null;
            try
            {
                ostream = new FileOutputStream(file);
                byte[] buffer = new byte[4096];
                while (true)
                {
                    int len = stream.read(buffer);
                    if (len < 0)
                    {
                        break;
                    }
                    ostream.write(buffer, 0, len);
                }
            }
            finally
            {
                if (ostream != null)
                {
                    ostream.close();
                }
            }
        }
        finally
        {
            stream.close();
        }
    }

}

JUnit creates a new instance of test class each time it runs a new test method and runs @Before method each time it creates a new test class. You can easily test it:

@Before
public void setup() {
    System.out.println("setup");
    when(myMock.myMethod()).thenReturn("hello");
}

And MockitoJUnitRunner will create a new MyMock mock instance for every test method.

It should be something like

@RunWith(SpringJUnit4ClassRunner.class)
public class aTest () {

    @Mock
    private B b;

    @Mock
    private C c;

    @Autowired
    @InjectMocks
    private A a;

}

If you want D to be Autowired dont need to do anything in your Test class. Your Autowired A should have correct instance of D. Also i think you need to use SpringJUnit4ClassRunner for Autowiring to work, with contextConfiguration set correctly. Because you are not using MockitoJunitRunner you need to initialize your mocks yourself using

MockitoAnnotations.initMocks(java.lang.Object testClass)

You can use content().string to verify body:

.andExpect(content().string(expectedContent))

Or content().bytes:

this.mockServer.expect(content().bytes("foo".getBytes()))

this.mockServer.expect(content().string("foo"))

JUnit 5

As of Junit 5.0.0 you can now annotate your test methods with @ParameterizedTest. So no need for inner classes. There are many ways to supply the arguments to the parameterized test apart from ValueSource as shown below. See the official junit user guide for details:

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.ParameterizedTest;
import org.junit.jupiter.params.provider.ValueSource;

public class ComponentTest {

    @ParameterizedTest
    @ValueSource(strings = { "racecar", "radar", "able was I ere I saw elba" })
    public void testCaseUsingParams(String candidate) throws Exception {
    }

    @Test
    public void testCaseWithoutParams() throws Exception {
    }
}

JUnit 4

If you are still using Junit 4 (I tested with v4.8.2) you can use the Enclosed runner in conjunction with inner classes and the Parameterized runner:

import org.junit.Test;
import org.junit.experimental.runners.Enclosed;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;

@RunWith(Enclosed.class)
public class ComponentTest {

    @RunWith(Parameterized.class)
    public static class ComponentParamTests {

        @Parameters
        ...

        @Test
        public void testCaseUsingParams() throws Exception {
        }
    }

    public static class ComponentSingleTests {

        @Test
        public void testCaseWithoutParams() throws Exception {
        }
    }
}

1. Right click your project in Package Explorer > click Properties
2. go to Java Build Path > Libraries tab
3. click on 'Add Library' button
4. select JUnit
5. click Next.
6. select in dropdown button JUnit4 or other new versions.
7. click finish.
8. Then Ok.

I agree with Jason that Play might just prove to be better than Grails. With four Grails projects under my belt (preceded by two Tapestry projects and one Wicket project), I'm seriously looking at Play next.

One of the things I thought was cool about Grails is that "everything's Groovy." That is, you use Groovy to write everything (except the HTML and the CSS) -- domains, controllers, services, page templates (GSP), tag libraries, Hibernate API (GORM), unit tests (GUnit), and build scripts (GANT). You can even write shell scripts in Groovy. So, being able to code all aspects of an app using a single language again seemed like a simplification that was long overdue -- hearkening back to the days of writing desktop apps in a single language like C++ or Delphi. However, I've learned that one size does not fit all here.

For one, the IDE support for Groovy isn't great. IntelliJ does the best job, but with Groovy being dynamic, it can only go so far. The refactoring tools do not (cannot) catch everything, so you can't trust them 100%. This means you have to be especially vigilant with unit testing. Here again, because Grails relies so much on dynamic "magic" that happens at runtime, the unit testing in Grails must rely on an extensive mocking layer to emulate it, and that mocking layer is quirky. A third issue is that much of the so-called Groovy code that you're writing is actually domain-specific-language (DSL) code. (To make a long story short, DSLs are short-hand Groovy, taking advantage of the fact that in Groovy and lot of the syntax is optional.) Grails uses different DSLs for various configurations, URL mapping, etc. and it is inconsistent. How you specify log4j settings, for example, looks nothing like how you specify the data sources, and neither looks like the pure Java upon which Groovy is based. So, the promise of "everything's Groovy" falls apart anyway.

That being the case, I see where the Play team is coming from.

1. Going back to regular Java for the domains, controllers, services, and JUnits makes sense. Strong typing means the IDE can reliably help with inteli-sense, code navigation, refactoring, etc. (And thus you don't need to pay for IntelliJ if you're happy with Eclipse.) Having to write more verbose code in order to gain back strong tool support seems like a good deal to me right now. We'll see.

2. I like that I still get to use Groovy in the page templates. I'm afraid I may end up putting more code in the templates than I should, though.

3. I have no experience with JPA, but it seems like it's pretty close to what GORM does for me, so that's cool.

4. The Spring IOC support in Grails is completely transparent whereas Play's support seems minimal; however, I think that IOC is way overused and I'm perfectly willing to hand code a Spring XML mapping on the rare occasion that I really need one. (One of my open questions is that I'm assuming that JPA has transaction support which is why Play doesn't need Spring for that like Grails does, no?)

5. I've never been a fan of Python, so I cringed when I read that Play uses Python for its build scripts. But I agree that Grails' GANT scripts run pretty slow. Plus I find that, while GANT is a huge improvement over XML ANT, it's still hard to wrap your head around the ANT concepts. The Grails GANT scripts are pretty convoluted. So, I'll go in to it with an open mind.

6. The Play "application module" model sounds to be just like Grails' "plugin" model, so that's cool.

7. I'm quite impressed with the Play documentation that I've read so far. I had a huge number of questions going in, but half of them were answered right off the bat.

I'll report back again later as I dive deeper in.

I developed a simple unit test framework for memory leaks which has worked reliably for me. The basic idea is to create a weak reference to an object which should be garbage collected, execute the test, perform a full GC, and then verify that the weak reference has been cleared.

Here is a fairly typical regression test using my framework:

public void testDS00032554() throws Exception {
  Project testProject = getTestProject();
  MemoryLeakVerifier verifier = new MemoryLeakVerifier(new RuntimeTestAction(getTestClassMap()));
  testProject.close();
  verifier.assertGarbageCollected("RuntimeTestAction should be garbage collected when project closed");
}

There are some things to note here:

1. It is critical that the object you wish to have be collected should not be stored in a variable in your unit test as it will be retained through the end of your test.
2. This is a useful technique for regression tests where a leak has been reported and you know which object should have been removed.
3. One problem with this approach is that it is hard to determine why the test failed. At this point you will need a memory profiler (I am partial to YourKit). However IMO it is still useful to have the regression tests so that the leaks cannot be accidentally reintroduced in the future.
4. I ran into some threading problems with not all references being cleared immediately, so the method now tries performing the GC a number of times before failing (as described in this article: Java Tip 130: Do you know your data size?)

Here's the full helper class in case you want to try it out:

/**
 * A simple utility class that can verify that an object has been successfully garbage collected.
 */
public class MemoryLeakVerifier {
private static final int MAX_GC_ITERATIONS = 50;
private static final int GC_SLEEP_TIME     = 100;

private final WeakReference reference;

public MemoryLeakVerifier(Object object) {
    this.reference = new WeakReference(object);
}

public Object getObject() {
    return reference.get();
}

/**
 * Attempts to perform a full garbage collection so that all weak references will be removed. Usually only
 * a single GC is required, but there have been situations where some unused memory is not cleared up on the
 * first pass. This method performs a full garbage collection and then validates that the weak reference
 * now has been cleared. If it hasn't then the thread will sleep for 50 milliseconds and then retry up to
 * 10 more times. If after this the object still has not been collected then the assertion will fail.
 *
 * Based upon the method described in: http://www.javaworld.com/javaworld/javatips/jw-javatip130.html
 */
public void assertGarbageCollected(String name) {
    Runtime runtime = Runtime.getRuntime();
    for (int i = 0; i < MAX_GC_ITERATIONS; i++) {
        runtime.runFinalization();
        runtime.gc();
        if (getObject() == null)
            break;

        // Pause for a while and then go back around the loop to try again...
        try {
            EventQueue.invokeAndWait(Procedure.NoOp); // Wait for the AWT event queue to have completed processing
            Thread.sleep(GC_SLEEP_TIME);
        } catch (InterruptedException e) {
            // Ignore any interrupts and just try again...
        } catch (InvocationTargetException e) {
            // Ignore any interrupts and just try again...
        }
    }
    PanteroTestCase.assertNull(name + ": object should not exist after " + MAX_GC_ITERATIONS + " collections", getObject());
}

}