I say test every public method; but that doesn’t mean property getters and setters (mutators) unless they do something more than simply set or return values. Sometimes, it makes sense to have a property that derives a value or returns a new object when one doesn’t already exist, etc.
Creating tests for private methods is debatable. I develop most of my methods public with tests, then go back and make obviously private methods private and remove the tests for them. Why? The methods that call the private method are implicitly testing those routines. The public methods are black boxes to the rest of the modules that have use for them.
When we do discover bugs in the code that your partner failed to notice while you were pairing, =write a test that recreates the bug, and then change the code until the test passes. These tests, though sometimes more functional tests than unit tests, become part of the suite.
Another situation where I see problems is when there are so many dependent objects and services that are involved in a test, including whole subsystems or databases. It’s impossible to create repeatable tests and that limits automation opportunities.
Let the vendor test the database. You use a mock object with the same interface. The same goes for web services and other pieces of the application. The other teams should be testing their work and mocking yours. Well, not mocking mocking – although it’s pretty common for competitive teams to actually mock each other – that’s not what I mean.
Eliminate the external dependencies and you’ll have more (predictable) fun testing.
Testing is good. Do more rather than less.