I encountered a defect arising from a Freemarker template, fixed it, and then wanted a better way of testing it than firing up the app and checking the effects visually in a browser. Ignoring for a minute whether or not…
I encountered a defect arising from a Freemarker template, fixed it, and then wanted a better way of testing it than firing up the app and checking the effects visually in a browser. Ignoring for a minute whether or not…
Some level of tests, let’s call it integration testing because it’s not technically unit testing, often need to load resources like XML samples from the file system. A talented developer I worked with recently, came up with this nice use…
It is still surprisingly common to see test methods named “test” followed by the name of a some method that’s going to be called. Sometimes you get a few words mentioning some other internal detail, like This sucks. I’m amazed…
What’s the best way to handle expected exceptions in JUnit? If you want to inspect the contents of the exception and make assertions against it then there is only one clean way; Use the ExpectedException JUnit Rule. I’ve seen it…
JUnit Rules are powerful things. There are all sorts of things you can do with a Rule that makes test code cleaner and less error-prone. Because a Rule wraps the test method, it’s really useful for things that need both…
In my first contribution for EasyMock 3.3 I have added support for processing the annotations with a JUnit Rule instead of the JUnit Runner. In 3.2 you could do this: @RunWith(EasyMockRunner.class) public class SomethingTest extends EasyMockSupport{ @Test public void shouldDoSomething()…
Look at this: With JUnit, that’s all you have to do make a method behave as a test. It’s clear at first glance that this is a test. That one simple annotation makes the method take on all the characteristics…