Interview questions

Today I’ve seen a set of interview questions. What actually caught my eyes was the following question/task:

Write a yesterday function, based on the Calendar API.

Continue reading “Interview questions”


TDD avoidance – Top 10 reasons

I’m sad to see we somehow got way too far from agile coding, best practices and quality. It seems that TDD has its life cycle curve inside our organization (who knows, maybe we can generalize further). At the beginning everyone is excited about the new way of working. They seem to be adapting things, trying out TDD, mocking and the other technologies. After a while, however, people feel test driving feature development is a waste of time. So they stop writing test cases and get back to their old way of working. At the end, the organization is left with very few people committed to TDD.

And this is the strange part. Quality drops, because nobody cares about it, but when it gets noticeable everybody cries around. And that is the point when people start shouting louder: “This code is pretty much a mess, we’d rather rewrite the whole thing”. A friend of mine told me the other day “you cannot expect people to be writing test cases; they lack dedication”. (By the way, in this case I wouldn’t expect them to be complaining about quality… but anyway) And I guess this is the point here. Lack of dedication.

I tried to figure it out, so I started walking around in the landscape and ask people why they don’t write test cases. Here is my top ten answers I collected. Are you ready? Ok, here we go:

  1. I am so smart I can implement this without test driving it
  2. I don’t know how to write tests
  3. This is a really small change, no need for tests
  4. This cannot break anything
  5. I’m in a rush, no time for TDD
  6. I wanted to write tests, but I didn’t 🙂
  7. It’d be too hard to test this mess
  8. TDD’s not a silver bullet. With or without it, doesn’t matter
  9. I’m prototyping
  10. I’ll do the real work, then you can play around with your tests

The sad thing is that I didn’t make up any of these…

I’d like to emphasis this one: “I’m prototyping”. It seems to me that as soon as people get to know about prototyping they get an excuse not to do TDD. Tricky prototyping this is after all. People write a bunch of code, call it a prototype and -guess what- check it in! Ok, first they cross their fingers and say “I hope this works”. So we fall back to Hope Driven Development (thanks for the term, Marcell).

And finally, number ten. I really heard someone say that when I proposed we do test driven development. Some people don’t even consider writing tests real work.

Sadly enough, people who already had the OMG moment seem to forget about tests (I call OMG moment when someone discovers how useful TDD is. Usually it happens when they miss a bug, but their tests catch it for them). One idea we could come up with is a regular TDD group, with the committed ones (this would involve regular meet-ups where we could teach each other tricks, techniques and other stuff. Perhaps after a while everyone will be confident about their skills, so we get several TDD mentors). Maybe we can place them in different  teams so they can “infect” others with TDD (they can insist writing quality code at pairwork sessions). Maybe it helps, maybe not. Any comments welcome.

Test overkills

I’ve seen kind of many times lately the following “pattern”;
Suppose we have a simple class, something like this:

public class Class1 {

    private String name;
    public String getName() {

And a wrapper class:

public class Class2 {

    private Class1 class1;

    public Class2(Class1 class1) {
        this.class1 = class1;

    public String getName() {
        return class1.getName();


And now a test case for the latter:

public class TestClass {

    	JUnit4Mockery context = new JUnit4Mockery() {

        final Class1 class1 = context.mock(Class1.class);

        public void shouldReturnTheValueNameForGetName() {
            Class2 class2 = new Class2(class1);

            context.checking(new Expectations() {
            Assert.assertEquals("name", class2.getName());

I mean why? Why would anyone put that value into an assert? It’s obvious that this assert will never fail. We told the mocking framework to return the value ‘name’ when the method getName() is called. Of course it returns the value we told it to return. So the assert is completely unnecessary there.

Of course, no one writes tests for getters… Don’t get me wrong, I’m not complaining about writing tests for getters. But still, people keep writing test cases that test values returned by the mocking framework. These tests can, at most, test the framework itself.

Anyway, values returned by expectations should never be tested. It’s like Assert.assertTrue(true); Tests that can’t fail are not testing anything. Tests that not test anything should be removed from test suites.