Test Cases

When good software engineers are designing a library or a program they usually take into consideration aspects of object oriented design, good practices, design patterns, anti-patterns, speed and reliability among other quality measurements available, but it's uncommon to see the user's perspective in the design.

It may sound weird if you think that software is primarily meant to the user, but there's a big lack of common sense among developers and the users are those who suffer more. If you get a snapshot of the software market 10 years ago you'll see all major software consultant delivering low-quality software, taking double the time and yet with less features than expected or agreed.

The legal battle was fierce but layers put into proper (incomprehensible) language and lawsuits are not a problem that common nowadays, but the quality is still lower than it should given that we have already half a century of proper software development. Cars and aeroplanes were already safe enough after 50 years of mass production.

The big deal is to take into consideration not only what the users requested, but what they'll actually see and use, and to avoid bigger impacts in the design it must be done quick, preferably before formal development. Test cases are a view from the user to your software and you should try to make it as simple as possible. When you know what steps must be taken, what information they'll have and need you can safely think of the interfaces and methods for running your part of the code and the inner methods will be much easier to map than if you'd start from scratch.

Growing from inside you'll give much higher value to small things that, when designing the small parts may seem important, but they're completely irrelevant to the whole. It also means that you'll probably optimize too early, bringing even more problems afterwards.

Test cases can also help assuring every part of your software is working, independently. It's normally a list of functions (units) that prepare the data, call a method and check the answer with the expected value, nothing else. You can prepare more than one type of data per unit and add several checks per answer but normally each unit tests only one method.

Whenever you change the method you should run that unit test (and all unit tests which functions depend on that one) to see if the output is still valid. Keeping the tests up-to-date is fundamental and you should never deploy anything if the test cases are failing.

After deployment you still need to assure consistency of your code for maintenance. Regression tests is the combination of running Sanity and Unit tests plus adding new tests to assure fixed bugs will not reappear in the code by writing small functions re-creating the scenario of the gub and checking the results.

Regression test is a routine that must be part of any further deployment of all software released and there should be no deployment without 100% of success in all tests.