This probably depends a lot on your own personal development style and whether your are coding by yourself or in a team. Clearly, if you're part of a larger team, having each developer unit testing makes a lot of sense. if you are the project, then you may get by fine with functional testing, particularly if your project is small. If your project has to be "bulletproof" then more rigorous testing helps you get confidence in the system. If you're doing something that should work if used correctly and the penalties of incorrect usage are the tough luck of the user, then a lighter, top-down testing approach may be sufficient. As always, TIMTOWTDI, and the right approach will be different in each situation.

That said, the advocates of test-driven development (which I'm starting to explore) would say that bottom-up unit-testing during development is the way to go -- you write your tests to express clearly what results you want and then code to that and build up from there. In the end, so what if your tests are "redundant" -- they were useful along the way to shape the logic of the system.

There is some logic in the test-first approach that applies even if you aren't doing test-driven development. In particular, if you are continually tuning or refactoring your code, running unit tests on the affected code is much faster than re-running a full testing suite after each change.

As a separate note, it's worth thinking about what you mean by "redundant". Just because a code routine or statement is executed more than once doesn't make tests redundant. My view is that redundancy means that test are:

• Independent -- the success of a test does not depend on the prior success of another test. (e.g., initializing the system, creating a certain state, etc.)
• Duplicative -- the tests identify the same failure condition.

A unit test may well be independent of a functional test, but the failure of the functional test doesn't necessarily tell you the same thing as the failure of a unit test. This is an issue of granularity -- when a failure occurs, how fast can you track down where and why the failure occurred? Thus, back the opening paragraph, if your project is simple enough that you have good transparency in a functional failure, then you probably don't need unit testing. But if your functional test failing leads you to go "Huh?" and start digging through code to find the problem, then some more granular unit tests would probably help you debug things more quickly. (Assuming that speed/efficiency are important to you.)