APL Wiki
WhyTestCases
Test cases are mandatory nowadays, and for very good reasons. This page tells why.
Note that the need for test cases is widely recognized in the IT industry despite the fact that the amount of resources needed to implement appropriate test cases is significant. In not exactly rare circumstances the time might be as high as the time spend to actually implement the piece of software subject to the test cases.
Reasoning
Quality
The most important topic about test cases is that they are designed to improve the quality of any piece of software dramatically. Not only that in a new project it's the way to go to make sure that the software is as bug free as possible before it's making its way to the customers. It's also about later stages: by changing code you will inevitably break code. But if you have a full-blown test suite ready to run against your changes, chances are that you find these problems.
That alone is a very good reason to spend the time on implementing test cases. On the long run this will actually save time and money for that very reason.
Examples
An implicit advantage of well-written and documented test cases is that they provide examples of how to use the software subject to the tests. If this is not true for all the test cases in a particular project, it is certainly true for some of them. By marking those you can easily create a pool of examples useful for any user of your software. That is a real time-saver for programmers joining the project later, for example.
Documentation
This is more important for APLers than for other people. Reason is readability.
Fact is that APL is harder to read than code written in other languages. That's a matter of fact. Partly this is caused by the simple fact that in one line of APL there is much more going one than in one page of COBOL, but it's also due to the usually higher abstraction level.
Now APLers often argue that one can always work out easily what a function is doing by using a debugger and simply watch what the lines are doing with the data. Due to the outstanding debugging facilities modern APLs are coming with this is certainly true. However, by definition this is true if and only if correct data is provided to the function in question.
Now that's a problem: when you get a bug report on your plate it's very likely to be caused by unexpected data, ill-formed data or data the application was never intended to deal with. With improper data you will have a hard time to find out what the code is supposed to do. It might be very costly or even impossible.
Test cases to the rescue! By definition Test cases provide valid data to functions and operators, so it is not a big deal to find out what the code is actually doing with valid data.
The big problem with written documentation is that nobody debugs it. Implicit documentation gathered from test cases is actually both, debugged and up-to-date. What an asset that is!
Strategies
The whole idea of automated test cases was triggered and developed by the agile approach. The obvious reason is that in agile projects, software is constantly updated, often every week or so. Whenever a developer has finished a task, she is normally supposed to check the updated code into the code repository. Before she is allowed to do this she must run the test cases. That's the only way to make sure that her changes won't break the code.
Early stages
There are all sorts of strategies. There are even people around who believe that in a new project the test cases should be developed first - Test driven Software Development (TDD). You might find this approach inappropriate for APL, and I would agree with that. However, implementing test cases when the software seems to be ready is certainly too late.
Later stages
It is obvious that when an application is changed or enhanced appropriate test cases must be added to the test suite.
It is probably less obvious that for every bug reported by a customer or someone else (yes, there are still bugs, despite having a test suite in place) that particular case needs to be implemented as a test case. There is a saying between programmers: A good bug will make a comeback...
Created 2009-03-20 by KaiJaeger