What's the right granularity for test-driven development?
Assuming you are speaking of Unit test driven development there are two things you need to get your head around first (or should I say, things I had to get my head around).
Both of them are actually about writing unit testable code (as compared to actually writing test first, etc)


Dependency injection: Avoid constucting objects inside other objects; instead, pass already constructed ones in through the constructor, or properties if appropriate. Look out for the new keyword and avoid it (exceptions apply, such as for classes that are pure data). Of course at some point objects need to be constructed. This should be done at high level classes (say somewhere near your console app's main()) at such a point that is simple enough to need no (unit) testing (since you won't be able to unit test it).
Dependency injection will allow you to inject mock or fake versions of the other classes you are dependent on.
Mocking/Stubbing/Faking/Test Doubles: Your unit tests should test only one thing, not all the things that one this is dependent on (they have their own tests). This allows you to localise (as in know the location of) any errors that show up. You can write your own stubs, but there are great libraries out there, and using them introduces a bit more consistency about how your tests work/look. NSubstitute is a good choice becuase it uses extension methods to be really easy to read.


As to the granularity for Unit Tests, it is as granular as you can go. That way you can localise errors (also the less granular/more integration test like, the harder is it to write tests, they become long). There is some argument about whether private methods should be tested or not. I would say it comes down to whether the private method is just a part of some public method (no) or it has its own well defined purpose (yes).

However, Unit tests driven development isn't the only kind: BDD (behavour driven development) focuses on Functional tests.