by Ron Jeffries, Ann Anderson, and Chet Hendrickson
Chapters 13 - 15 of Extreme Programming Installed focus on testing and releasing your code. The most important point of Extreme Programming is that testing is done first, along the way, and 100%. This means that before you even write any code, you first write a test for that object or class. For example, if you're testing a class that will compute the sum of a list of numbers, you can first test what happens with an empty list. The test will fail, so write the code that makes the test pass. After that test passes, you might test what it outputs with a single number in the list. Again the test will fail, and you should write the code that will compensate for that test. The point is that we test first, and bit by bit as we are writing the code. And every time we add code we make sure that 100% of the unit tests pass before we are allowed to release the code.
When we are writing code and testing, we also make sure to code "by intention." This means that we write the code based on what we need to do, not exactly how we're going to do it. For example, if we need to compute the roots of a quadratic equation, there are a couple steps. First, we need to compute the discriminant, then take the square root of that (if it's not negative), and then compute -(b) +/- discriminant over 2*a*c. When coding by intention, we will first make function stubs for each of the steps (compute discriminant, etc). Then, in main, we will use each of those functions to calculate the roots. After running the tests for the whole system, they will all fail. Then we will worry about exactly how we compute the discriminant and all of the details. The main point is that first we programmed our intentions.
The last chapter in this section dealt with code releasing and version control. The most important point is that Extreme Programmers release often, usually more than once a day. They don't wait for other people to finish the work that their code may depend on, and don't even really check to see if someone else is editing the file at the same time (at least past what the versioning software will do). In practice, you will spend more time trying to avoid conflicts instead of just working and addressing conflicts if they do show up. The versioning software that you use should make committing releases easy and quick; if programmers are releasing their code less often because of the versioning software, you need to change the software and make it easier for the user.
I think that test-first development is a great idea. Writing all your tests first helps you understand exactly what you need to accomplish in your code and helps keep you on track. But, in my experience, it is horribly boring and annoying to do. As a programmer, you want to start working on the real code, on the code that makes the product work and what customers will directly interact with. But instead you're writing a test for a class that you haven't even written yet. Is that test going to fail? Well, duh. It's hard for me to see the value in writing a test before you have even written any code. Maybe just writing it, but running the tests? It doesn't take a genius to know that they're going to fail. I think it would be much better to write some of the code and then start testing on the way. That way you're not wasting your time writing tests that you know are going to fail but instead you're writing tests to help you find problems with code you are currently working on.
No comments:
Post a Comment