Tomasz Nurkiewicz around Java and concurrency

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 lin

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