The art of testing software is one that ensures that whatever you are developing is not going to cause any trouble to anyone that uses it. Whether that is your customer, or even yourself, are going to have the best experience when using the system you built.
Test driven development (as I mentioned it in HFOOAD Chapter 9 – “The Software is Still for the Customer”) is one where you plan the tests and develop software around them. At all times you want to test that new function, method, class or piece of code that you just made.
In OO things change a little bit, because this paradigm comes with a lot more capabilities and ways to develop the same thing. In OO test driven development you don’t only think about what can make your functions behave in a way that they are not intended to, you have to take into consideration some other things: how objects behave in the language you are coding, how inheritance could break your code, how polymorphism affects your system, and so on.
The general advice (and this applies to every software paradigm there is) is to test everything that that paradigm brings to the coding scene. If you are working with objects, test those objects, if you are developing in functional programming, test those functions, if you like modular programming, test those modules and how they interact with each other.