There are techniques in the book but really you should try to write tests for code as you write it. It's the best way to make sure that your code is decoupled enough for testing. If you do that, you don't need the techniques in the book.
Edit: For those that don't know Kent Beck is basically the godfather of TDD.
[1] http://www.amazon.com/Test-Driven-Development-By-Example/dp/...
[2] http://pragprog.com/screencasts/v-kbtdd/test-driven-developm...
"I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don't typically make a kind of mistake (like setting the wrong variables in a constructor), I don't test for it. I do tend to make sense of test errors, so I'm extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong."
http://stackoverflow.com/questions/153234/how-deep-are-your-...
Read Growing Object-Oriented Software Guided By Tests. The authors walk through the development of an auction sniper.
Every test is another thing that has the potential to require debugging.
It's a tad long, but worth it. tl;dr: the first half agrees with you, and the second half describes a process that does help you test useful stuff (and design your software decently along with it)
I wanted to start adding unit tests a couple of years back, but looking back, I don't think it would have gained very much, and cost a lot of time (creating the data to test the parts).
If there is a functional unit that does one specific thing, I could see it being useful to test. But most of my app basically queries a database and displays the results. The bugs I do get would rarely have been caught by unit tests.
Other than that, just be explicit about your api contracts and test those.