I've been meaning to write about this for a little bit, but first check out a Jay Fields post Ubiquitous Assertion Syntax. I really like the idea that tests follow a similar structure and I'm okay with the JUnit style.
What's important to me is that the assertions always come at the end of the test and it's clear what you are asserting, without needing to rely on the method name. Here's an example:@Test public void methodFoo_should_do_X_when_Y() { test setup test setup test setup assertEquals(a, b); }
How a Mockito test might look:public class Foo() { private Bar bar; private String something = null; private String somethingElse = null; public Foo(Bar bar) { this.bar = bar; } public void setStuffUp() { this.something = bar.a(); this.somethingElse = bar.b(); } public Foo callBarC() { return bar.c(something,somethingElse); } }
How an EasyMock example might look:@Test public void callBarC_reallyBadTestName() { Bar bar = mock(Bar.class); Foo foo = new Foo(bar); when(bar.a()).thenReturn("A"); when(bar.b()).thenReturn("B"); foo.setStuffUp(); foo.callBarC(); verify(bar).c("A","B"); }
@Test public void callBarC_reallyBadTestName() { Bar bar = createMock(Bar.class); Foo foo = new Foo(bar); expect(bar.a()).andReturn("A"); expect(bar.b()).andReturn("B"); expect(bar.c("A","B").andReturn(null); replay(bar); foo.setStuffUp(); foo.callBarC(); verify(bar); }
In the Mockito version it's clear what behavior you are testing... it says verify(bar).c("A","B"); But in the EasyMock version the code itself does tell you what you're testing, you have to rely on the bad test name. You could argue that I'm testing all the expectations, but most often you're not. It's not uncommon to have two mocks one that sets up state for another one, the one you're really interested in testing, the focus of your test. Something like:
@Test public void verifyBar2_is_called_correctly() { Bar1 bar1 = createMock(Bar1.class); Bar2 bar2 = createMock(Bar2.class); Foo foo = new Foo(bar1,bar2); bar2.foo(); expect(bar1.a()).andReturn("A"); expect(bar1.b()).andReturn("B"); expect(bar1.c("A","B").andReturn(null); replay(bar1,bar2); foo.setStuffUp(); foo.callBarC(); verify(bar1,bar2); }
In this example except for the test name, it's unclear what the intent of the test is. Here it is in mockito
@Test public void verifyBar2_is_called_correctly() { Bar1 bar1 = mock(Bar1.class); Bar2 bar2 = mock(Bar2.class); Foo foo = new Foo(bar1,bar2); when(bar1.a()).thenReturn("A"); when(bar1.b()).thenReturn("B"); when(bar1.c("A","B").thenReturn(null); foo.setStuffUp(); foo.callBarC(); verify(bar2).foo(); }
In mockito, even if I put in a bad test name, the syntax of the test preserves the intent. This is really important. Easymock was a great library, but I think as Jay put it Mockito starts to bring us to testing 2.0
The google testing blog just published an article Use EasyMock I guess I just disagree. Mockito grew out of EasyMock, and I think they took a great library and made it even better, so I really think the title of the post should have been "Use Mockito" not EasyMock. Anyway... there's a whole lot more that Mockito does check out the examples and get off the EasyMock and start drinking the Mockito :P
No comments:
Post a Comment