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.
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.