Problem Solving Techniques?

What you are asking is somewhat central to the idea of Test Driven Development ("TDD"), which is turning out to be more coding religion than a best practice. I am an old dog learning new tricks and don't typically criticize something unless I have tried it and explored most of the corners.

I think I properly understand the issues surrounding TDD and the problems it is trying to solve but I have not been a convert to the central notion of writing an API, then the tests for it, then the actual code.

If you ask ten other people the same question you will likely get 4 or 5 unique opinions.

I have two advices regarding test cases:

Briefly:
1. Sometimes (often) you don't need test cases at all.
2. The most important thing is to define the interface of the library well. The order in which you implement code on the two sides of the interfaces is unimportant (matter of taste). One side of the interface contains the code of the library itself, the other side contains different programs/other libs (including the test cases that counts as one user of the lib). I add an important note here: The world ins't perfect and requirements often change. Don't dream about the perfect interface and don't spend weeks designing it. Sometimes the interface must be changed when extending it isn't enough and in this case you have to adjust both the library code and the code of the library users (including the programs and test cases).

I have worked on some large codebases that made use of extensive unit testing. At the same time I've seen rolling and successful large projects without a single test case. Some projects (like the current one I'm working on) has test cases only for some of the libraries (for example our builtin script compiler) but our build (final built product) and its core features are constantly under testing (we have a department with a few QA professionals). Most of the code of our product changes too rapidly so the costs of unit testing would outweigh the advantages we would gain by unit testing.

When to make unit testing? Unit testing has several advantages and disadvantages.

- Advantages:
Easy to introduce new features without screwing up old features (you can test the old features after modifying the code). If the reliability of some libraries is important then writing tests for them is mandatory (for example libs used in the control software of an airplane). Another advantage in my opinion: with test cases the library interface has at least 2 users: The program that uses the library in the final product and the test case (that is another program using the lib) and this forces people to define cleaner interfaces and automatically prevents some lazy coders to push half of the code of a functinality to another libarary -> better separation of concerns on source code level.

- Disadvantages:
If a codebase is exensively tested then the test code can be half or more of the whole codebase! This involves extra maintenance that can be extremely costly (time/money) depending on the frequency of changes in old code. In rapidly changing code sometimes testing would terribly slow down the development process. For this reason sometimes the only interface that is tested is the user interface and important functionalities of the ready-made compiled program by QA people. :-)

Finally development is almost always about time and money. Someone at your company has to decide whether test cases are useful/useless in a given scenario and whether you have the time/money to invest for the advantages of test cases or not. Saying that unit testing is always good isn't fair, sometimes you pay much more than what you gain by unit testing.

Generally, you design your algorithm to include the the "special cases" - you then design tests to cover the algorithm, not the cases you have specified and coded.