Where he blogs about his eclipse musings
Posts tagged testing
Mockito – one of the better mocks
Mar 5th
Now that I’ve got your attention. Mockito is not just better than the other mock frameworks out there, it’s infact the best out there.
After reading a lot of noise from fellow ThoughtWorkers in the recent past about Mockito. I decided to give a yet another mock framework a try.
Here’s what I ended up writing:
public class RecorderLauncherTest extends TestCase {
private RecorderListener listener;
private RecorderLauncher launcher;
private TestRunner runner;
protected void setUp() throws Exception {
super.setUp();
listener = mock(RecorderListener.class);
runner = mock(TestRunner.class);
launcher = new RecorderLauncher(runner, listener);
}
public void testNotifiesListenerWhenLauncherStarts() throws Exception {
launcher.launch();
verify(listener).start();
}
public void testNotifiesListenerWhenExecutionFails() throws Exception {
stubVoid(runner).toThrow(new RuntimeException()).on().run();
launcher.launch();
verify(listener).start();
verify(listener).error();
}
public void testNotifiesListenerWhenExecutionCompletes() throws Exception {
launcher.launch();
verify(listener).start();
verify(listener).finish();
}
}
What’s even nicer is that it’s actual code and not strings, and refactoring tests do not break my mocks.
Good bye expect-run-verify, hello run-verify.
This looks, and reads far better than the JMock syntax, and it was love at first sight; I’m test-infested now. If you have not tried mockito as yet, I’d recommend that you do. I’m sure you’ll love it too.
Controller Testing in Active Scaffold
Dec 27th
I just started my adventure with rails a few nights ago. Figured that Active Scaffold based controllers do something that is different from the default controllers generated by the scaffold generator.
For one all controller tests broke when I moved to active scaffold. Here’s a blog post that talks about testing active scaffold based controllers.
Eclipse and TDD (Part 2)
Oct 14th
This is in continuation to my previous post “Eclipse and TDD“
I feel that the question that I posted “Given this scenario, how do you do test-first-development ?” needs some clarification:
There’s one interface that needs to be implemented to accomplish a certain task. This one interface is supposed to return some more interfaces. Also you’ve never used those interfaces before, makes things unpredictable in some sense. You therefore end up taking small steps, try out a few things here and there, see what happens as you go along, and your implementations evolve quickly over the period of a few minutes. By which time your implementation is complete, and you have not written a single line of test 
You then quickly get to refactor the code that you’ve written to make it “testable”. This code was never written with “testablity” in mind in the first place, so it will never be testable in a way that you really want it to be.
The problem to me seems to be the fact that the “expectations” from the interface are not known before the tests are written.
So does this mean that:
- I need to better understand the interface before I start using it ? Read the JavaDocs, other implementations that do something “similar” ?
- Assuming that I do understand (to some certain extent) what the intent of the interface is, and I go ahead and implement that interface — the test-first-way. I know for sure that this may not really work in a way that I want it to, so I can go ahead and change bits and pieces to suit my needs.
- Write a test harness like cactus for every such possibility — this I know is a crazy solution but one that would gurantee testability. This would also create additional problems of having to maintain the test harness at a pace equal to the pace of what the harness is trying to test.
Eclipse and TDD
Oct 13th
It’s been after quite a while that I’m back to doing eclipse plugins. In this span of time I learnt some good techniques — TDD. It’s a really good safety check to know that your code is in a working state.
Test-first-development or TDD as it is called is where you generally write tests first and then write code that makes these tests pass. This in some ways ensures that you write clean APIs that are simple to test, use and understand. The APIs don’t really do more that what is needed for the job. So far so good.
The fun began when I moved back to doing eclipse. I now realize that it is difficult to do TDD when I’m writing code that implements (or extends) some third party interfaces. These implementations return some more interfaces, which only compounds to the problem of test-first-development.
The way I write eclipse plugins is create a null implementation that does nothing at all. It merely prints method names of the methods being called on to the console. I then start off eclipse (in debug mode), understand the sequence in which the interface is invoked, and what eclipse does with the return values (that’s walking though a lot of code, BTW), I also sometimes need to look at similar implementation to understand what they do. I then gradually implement those methods in a way that what eclipse expects. This gives another meaning to BDD — breakpoint driven development.
This process is what most developers would probably do when using a framework for the first time. Most frameworks (unlike the eclipse frameworks) are much simpler than eclipse is. There are some known interfaces that are exposed. Since there are very few interfaces to implement, developers gradually get to know them very well. As the expectation out of these interfaces is known well, gradual use of these interfaces, makes it easy to write tests for the interface before implementing the interface itself, which means that developers can move from BDD to TDD.
This process is a quick (and IMO, dirty) way of writing code. The initial code is not written with testability in mind, writing unit tests at the end is quite difficult, and testability can be achieved after quite some bit of refactoring to allow make the code testable.
An example of this is a typical java webapp that consists of some servlets, and jsps containing tag-libs etc. There are very few known interfaces that the clients implement (the HttpServlet, Filter, FilterChain etc.) Since the webapp framework itself is very compact, a framework to unit test the implementations of interfaces exposed by the servlet spec has evolved over a period of time. Cactus is one such example:
Cactus is a simple test framework for unit testing server-side java code (Servlets, EJBs, Tag Libs, Filters, …) [...] It uses JUnit and extends it.
To test a servlet one would write a test as:
public class TestSampleServlet extends ServletTestCase {
public void testThatServletPrintsHelloWorld(){
Servlet servlet = new HelloWorldServlet();
...
session.setAttribute("name", "bob");
...
assertTrue("hello, bob", servlet.printHelloWorld());
}
}
It is mind boggling to imagine a framework similar to cactus to test the thousands of interfaces exposed by a framework like eclipse, and we are still not talking about the other, “smaller” projects under the eclipse umbrella.
Given this scenario, how do you do test-first-development ?