When should I design and document my test cases?

Question

IN SDLC, the Testing procedure should be right after implementation. However, Test-driven development encourages us to do testing while doing implementation. And in my lecture course, Prof said test cases should be part of the design.

I am a junior developer, to implement a new feature, when should I design and document my test cases?

I found that it is not so practical to test all the cases after finishing the implementation. It is because once a cases is failed, I have to change the codes and retest all cases again. Is there another way to overcome and avoid this? I know automated testes is one of the solution, but somehow, automated testes cannot stimulate all of the test cases, especially integration test cases which involves different parties.

Also, in my test cases, should I test all parts of the code? OR just test the functionality of that features request? OR it actually depends on how much time you got?

Many thanks.

Answer 1

Your question isn't so easy to answer, because, as you say, "it actually depends on how much time you got." Here are some opinions though:

Test after implementation: No

As a programmer, you're an expensive and scarce resource with multiple deadlines stacked up on top of each other. So effectively, this means "never test". After you've implemented one chunk of code, you will move on to the next chunk of code, and mean to come back to write tests "when you have time" (you never have time).

There are also the problems you mention. If you do all your testing after the code is written, and your tests discover something fundamentally wrong, you have to go back and fix all your code as well as all your tests.

Test while implementing: Yes

This method is actually really helpful once you get a rhythm for it. You write a bit of a class, then write a bit of a unit test, and continually revise your tests and your code until you're finished. I believe it is actually faster than writing code without tests.

It is also particularly helpful when working on a large project. Running a unit test to see if a little module is working is instantaneous. Building and loading your entire application to see if a little module is working may take several minutes. It may also interrupt your concentration (which costs at least 10 minutes).

What to test: As much as possible

100% test coverage is probably never practical. But absolutely test the critical pieces of your program, things that perform mathematical computation or lots of business logic. Test everything that's leftover as much as possible. There's no reason to test a "toString()" function, unless that happens to be critical to business logic or something.

Also, keep your tests as simple as possible, just inputs and outputs. Most of my test functions are two or three lines. If your function is hard to test because there are too many combinations, it's a sign that your function might need to be broken up a little bit. Make sure to test edge cases and "impossible" scenarios.

Answer 2

My experience:

1. Document your tests with if the code is not self-explanatory or if the case being tested is a 'tricky' corner case which is not obvious at first sight (although the code may be).
2. Don't create separate documents for your tests. Put everything in comments and Javadocs if you are using Java. In other words, keep this information close to the code. That's where it is needed.
3. About designing and implementation: just iterate. Write some implementation, then a bit of testing code for it, then more implementation code, etc... until you are done with both implementation and test code. It goes faster than writing all implementation, then testing, then rewriting failing implementation code. You can't anticipate all tests to implement at design time, it is impossible. So, no worries if you don't get it all.
4. If you cover more than 80% of the code you are already good, more is better. Sometimes, code can't be tested. I recommend using test coverage tools, such as Emma for Java.

OR it actually depends on how much time you got?

The time you save by not testing is never ever ever paying for the time you have to spent to solve bugs later in the project. A proper test set always pays a lot down the road, always.