On the subject of what kind of tests do you need to write: with any new app, I generally only write a few (perhaps TOO few) tests; just enough to show that the main features of the product work. In the process of getting there, I generally find that I've tested many features that will never break again. Of course, for critical code, we also test to be sure that all of the features needed /can/ work, and that no corner cases cause a crash. But that's about it for the first round of development (at best, this would be pre-alpha quality code).

It's later, when bugs are discovered or new features are needed, that I tend to do the most testing. I'm very big on regression tests: if something changes, show me a test that compares that change to the previous, and coverage tests: if I wrote this block of code, show me a case that either tests it, or tell me why you can't (and consider removing same).

All of these are fairly basic ways to handle things that come up often in testing where I am. What I'd love to find is a way to test for third-party code authors that do stupid things for no reason (such as allocating a buffer every time through a loop, in C code, rather than moving the allocation outside the loop), but I haven't found any good way to write those...