Preface
"Whatever you do today will get you one step closer or one step further from the intended goals."
How can this statement be reflected on the idea of Unit testing? Unit testing is usually seen by people as the additional cost related to development. If you do not write additional lines of code we save time. We could spend this time writing production code, for example.
Well this is only partially true. In many cases we [mistakenly] assume that writing a line of unit the same as writing a line of production code. This leads us to incorrect understanding of unit testing benefits.
Testing code is as simple as it takes 10 to 100 times less time than writing a piece of production code of the same size. So, do not even listen to voices of people who claim that development with unit testing takes 1.5 to 2 times more time based on code line calculation.
Unit tests are trivial, as simple as code below. Just think of how many such tests you can write in the course of an hour...
public void testAddNegative () {
assertEqual(MyClass.Add(2,-1) , 1);
}
Supporting unit tests after change is as trivial as writing them. You can even afford rewriting them from scratch with easy.
Why to unit test?
If you can write code without error you would probably not need to test it. If you cannot write code without error them how do you check that it does what it should do? Using debugging is a tiresome tedious manual activity, not in the way how developers are meant to do it. Not to say this is hardly possible to run all required tests in debugger after changes. I know no developer who would do this stupid thing.
So, having produced a piece of code with undefined quality developer simple gives the responsibility for testing it away to someone else down the line. Let's see if there are right people to do it. Hm...
Integration engineers are supposed to see your modules as black boxes. So, they do not care about your inner functionality. All they work with is external interfaces, input and outputs of your module. If there is a branch in the code that was never tested it's very probably remain such after Integration testing.
The next possible candidates to catch your defects are system testers (or QA as they called sometimes). These guys care about code structure even less than integration and deployment engineers. Testers focus on business logic. Their job is to make sure the ideas you have implemented is exactly what customers wanted. Testers care about neither code structure nor architecture. If they catch your intrinsic code error it is only by chance.
The next in the food chain is the end user. Unfortunately those guys are extremely lucky at finding the issues. If you leave defects in the release system be sure they will stumble upon it %)
There is no one down the line who can catch and correct your code errors. Only you, as a developer, can check if all branches through the code are examined carefully. Only you are responsible for quality of code that you check into the code base. So, find time to test.
How do you know you are done?
How developers get to know that code piece is done? If they have automated unit tests then this is not a problem to run them and see the results. But what is there are no tests? Do such developers have habit to provide to someone code of unknown quality? Just imagine what if cars were made using the same attitude.
Having your code run under debugger with 1 typical data set is not enough. There are boundary conditions, zero and incorrect input, big volumes of data, stressful conditions that also can lead to failures. Who of developers do such testing under debugger? I guess no one.
So, there is no other way to make sure you finished the code but Unit testing. If you know a reasonable alternative to Unit testing just drop me a line and I'll fix this statement and will eat my hat ;)
The most effective unit testing
Unit testing has proved itself as a powerful tool against software regressions (issues that appear after changes or defect fixes). So, the more changes you do to the project keeping tests untouched the more return of investment you have.
Who does unit testing?
To me the answer is simple - developers should do it because:
* They know the code and there is no need to explain it to someone else.
* They think of testing during code design.
* They need something to demonstrate that the code is finished.
The crude world
If unit testing was so easy it would not be so difficult to start. Yes, there are problem. But there is none that was not faced and overcame by someone else. If you faced a problem just look around, ask your peers, search Internet but don't give up! You need unit testing anyway.
While talking about unit testing with developers I was often asked for recommendations on testing:
* Databases
* JavaScript
* UI
No problem. Just try Google for any of these to see how many possible solution you have at hand.
Wrap up
All you need to do unit testing is to start it. And do not lay it off until tomorrow, start today. As the final reason I will tell you that developers who do unit testing prove to be more successful than those who test under debugger. If you do not start today you waste critical experience and fall behind your peers. Do not be surprised if someone of them will suddenly appear one step higher in the company hierarchy ;)
No comments:
Post a Comment