eXtreme .NET: Introducing eXtreme Programming Techniques to .NET Developers [Electronic resources] نسخه متنی

Eddie: Test-driven development is really important, so I want to make sure you know why we are writing code this way

Sue: Why do we need tests in our code at all?

Eddie: What is your job? Think hard enough about what we're being paid for here. As a developer, I believe that I should aim to write bug-free code. It is my job to test my code before shipping it, and I know that I can write code that tests my code.

Pete: Isn't that the job of the testers?

Eddie: This is my job, and if you write code, and have any pride in the work you do, then it is your job also. The testers should be there to validate we have written zero-defect code. Any time the testers do find a problem, it is our job to fix that problem and make sure it never happens again. If you don't believe your job is to ensure the work you do is of the highest possible quality, then I would seriously question your integrity and what you are actually doing here at work.

Pete: Panic!

Deepak: Why do we have to write test code?

Eddie: The best way for me as a programmer to validate that a function behaves as I expect is to write some code that tests that function. Writing tests in my code has many advantages for me:

I am less likely to have the code returned to me from the QA department with some negative comments attached.

I am more likely to get a good response from my customer.

With tests in my code, I am more confident that any changes I make don't cause side effects in other parts of the code.

The tests validate my beliefs in how a piece of code is working. The tests document my theories and beliefs.

The tests give me confidence in the functionality I am providing.

I am happier to share my code with other developers, knowing that the tests will break if they do something that causes my code to fail.

Pete: Why not do manual testing?

Eddie: Manual tests introduce the possibility of human error entering the system, and, if like me, you occasionally get a little lazy you might be tempted to skip some (or all) of the manual tests. Manual tests are much harder to replicate. To replicate manual tests, we would require some documents with steps to take when carrying out the tests. The documents would quickly become out-of-date as the code changes, and that means more work to keep the documents up-to-date. Finally, manual testing is boring, although we can't use this as a good justification for our manager. Why do something manually when we can write some code to do it for us? We are programmers after all; let's use our skills for our own benefit!

Ultimately every piece of software has some aspect of manual testing applied to it in the form of visual checks and validations. Just don't rely on manual testing to provide anything of value for us on a regular basis.

Sue: Why write the test code before the "proper" code?

Eddie: I believe that one word answers most of this question: focus. Writing the test code first helps me to focus on writing the simplest code that will make the tests run. The tests define the pre- and post - conditions of a piece or unit of functionality, and this sets the boundaries for the code to be written.

Writing the tests first helps to keep the unit of code being written small and testable. It is an obvious side effect that if we write the tests first, the code we write must be testable because we've already written the tests for it! If we choose to write the tests afterward, we could easily find that we have units of functionality for which it is hard to write tests. We would then need to break the units down into testable units. This effort is wasted if we can avoid it by writing the tests first.

Chris: Why doesn't this whole process cost me more?

Eddie: In my experience, test-driven development has proven to be cheaper for the customer. The tests ensure a higher level of quality from day one. The biggest expense in software development has traditionally been in the maintenance and upgrade stages. The tests embedded in the code reduce each of these costs dramatically. Maintenance becomes easier. Defect diagnosis is aided by a suite of tests in the system. Fixing bugs is far less likely to cause any ill side effects if none of the tests in the system fail. Making an upgrade to a system that has tests will be easier because the whole system can be regression tested for changes in functionality.

This reduction in cost is so large that I believe as more systems get developed that have testing built in to them it will be very difficult for other systems to keep up with the pace of change.

Whole team: Thanks, Eddie.

Beware The Cheap Customer

A customer who doesn't want to pay for testing is a customer who doesn't want to pay for quality. This doesn't mean they don't want it; it just means they don't want to pay for it! Unless your customer is asking you to knock up a prototype that you will then throw away, you have a customer who wants quality.

Many years ago, when I was far more naïve, I was running a software company. I had a customer who had a proposal for a very interesting project. They asked us to bid for the project, and we put in a proposal to carry out the work. They came back and negotiated the price down, saying they didn't want to pay for the testing; stupidly, we agreed. We put a clause in the contract saying we didn't assure any level of quality with the software produced. Over the course of the next six weeks, we knocked out huge quantities of code that basically did the job. We shipped the code to the customer, who promptly turned around and threatened to sue us because the quality was so poor. The software crashed every so often and wasn't consistently providing the data in a timely manner. We pointed the customer to the clause in the contract and said, "But you didn't want to pay for testing, so we didn't do any; of course it might crash!' After much wasted time and effort, we came to an arrangement where the customer agreed to pay some more for the software to be tested and any bugs fixed.

Needless to say, I learned my lesson (the hard way): I will never again allow a customer to drop the price and remove testing from the schedule. If they want to drop the price, a customer must drop functionality. I am not prepared to develop buggy code; it costs too much money, time, and effort in the long run.