Testing for exceptions in JUnit revised

In his recent post the author of fantastic mocking framework Mockito collected few rules about testing exceptions. What caught my attention is the advice to use JUnit rules (nomen est omen!) for testing exceptions. ExpectedException rule gathers advantages of both expected @Test attribute clarity and try-catch strictness. Here is the example:

public class DefaultFooServiceTest {

 private FooService fooService = new DefaultFooService();

 @Rule
 public ExpectedException exception = new ExpectedException();

 @Test
 public void shouldThrowNpeWhenNullName() throws Exception {
  //given
  String name = null;

  //when
  exception.expect(NullPointerException.class);
  fooService.echo(name);

  //then
 }

}

Szczepan claims that ExpectedException fits into given/when/then test template nicely. I disagree! Look at the code snippet above – what is the most natural place to put assertions on exception being thrown? From the obvious reasons it must be the last line before the line that actually throws the exceptions. So you have a choice to put assertion as the last statement in given block or as first in when block. You are right, this is how this test should look like in an ideal world:

@Test
public void shouldThrowNpeWhenNullName() throws Exception {
 //given
 String name = null;

 //when
 fooService.echo(name);

 //then
 exception.expect(NullPointerException.class);
}

JavaScript dynamic language support in Spring framework

Miško Hevery’s blog post about JavaScript opened my eyes and changed the way I thought about this language completely. Miško practices TDD and advices this technique at every occasion. JavaScript, being dynamic language, needs tests even more than statically and strongly typed languages. This immediately invalidates main objections against JavaScript and dynamic languages at all – that lack of compile time checks inevitably lead to poor quality and runtime bugs instead of compile time. But what is more convincing to you: that your code passes very strict compile time rules or that it passes unit tests covering all the use cases?

After going through the first few chapters of Object-Oriented JavaScript... I couldn’t help myself to try this new, very productive language with functional aspirations. But then I realized that, unlike Java, JavaScript misses:

• good runtime environment: it’s hard to name handful of web browsers, each implementing different dialect of the language, decent runtime
• good development environment: debugger, editor with code completion, profiler – I mean, Firebug is wonderful, but...
• testing capabilities – aforementioned vast number of web browser in countless versions, actually, how to run such tests on your continuous integration server?
• server-side attitude. C’mon, I’m a back-end guy, running my code inside a web browser to manipulate page DOM and debug using browser plugin? This just doesn’t feel right. Let me run this script clustered on a farm of 16-core servers to make me excited!

And when I say server-side, I mean Spring Framework. The idea to run JavaScript on server-side isn’t new, so it would be nice to introduce JavaScript in Spring. Since version 2.0 Spring supports developing beans using few dynamic languages, namely Groovy, JRuby and BeanShell. The support includes: