TDD A Religion not Process

Now a days at work I can safely place TDD to the side, even though my boss would love me to practice it. At the moment I’m working in a large, legacy code base. This code base is about 3 years old but looks like it’s thirty :). Let me not get distracted.
Some how TDD has infused itself into my brain today. I can’t stop thinking about it. All the resources out there would make you believe that TDD is some process that all you have to do is adopt and it will lead you to the promised land. In reality, I believe it’s more like a RELIGION. You have to first find your faith and then perform the rituals before the promised land materializes.
I’ve been practicing TDD for over 2 years now and I still find it challenging. Anybody can write unit test after the fact, but only the best developers know how to make great decisions throughout a project. And it’s this ability to make quality decisions consistently that I struggle with day to day. It’s a design activity after all.

Here are couple of very high level challenges which I think I have with TDD

1. How to determine at what scope I should write a test
2. Make sure I capture behavior and not implementation details
3. Learning not to over mock
4. Force myself to write only enough code to make the test pass

There are other challenges which I have seen in projects, when a team does TDD like slowness of tests so team stops running all the tests or UI tests which tend to be fragile, because they often fall because of refactoring. So they often become fragile, failing
erratically and difficult to maintain.

Humm I am thinking of elaborating my bullets points, nahhhhhh not today probably will do that in my next blog.

Manisha

Remember to give a hint

We ran into once interesting discussion during our last code review session. As we all do it's a common trick to use relax access restrictions to test a particular property/method/function, so that you can use it in a unit test, which resides in the same package (though in different catalog).

Whether you think it's good or bad, I believe always remember to give a hint about that to the developer. A simple annotation that tells you why a particular property access restriction has been relaxed.

Consider:

public class foo {
private Long x;
String y;
}

Hummm Why is 'y' package scoped?

public class foo {
private Long x;
@VisibleForTesting String y;
}

Ah, that's why

Nice isn't it.
Manisha