Ron Jeffries, Ann Anderson, and Chet Hendrickson
These next three chapters cover unit tests, test driven programming, and how to handle release changes. For unit tests, the programmer needs to be able to test every single class and method and that test needs to run 100 percent of the time. We do this by writing code that tests each method or class within our current project code. This can be quite overwhelming especially if you have a large project. That is where the next chapter comes in. Basically, in extreme programming, you want the tests to drive the coding. Why write new code when your tests already tell you that the current code can handle everything you need it to. You should only write new code when one of your tests fails. Also, XP is notorious for lack of planning. They don't focus on how to do something, rather, on what they need to do. This is called programming by intention. Collective code ownership is very important to XP. It allows things to get done faster and at a higher quality since programmers don't have to wait for permission. At the same time, releasing changes becomes a lot more important. There are three main steps that pair typically follows which are called local, release candidate, and released to the repository.
I have never really used any of these ideas too much at work but I know they are used on some of the larger projects. I know that unit tests are important but sometimes i feel like they take more time than the actual coding process. I think there needs to be a balance between how much testing as done and the actual coding. If you focus on too much on one aspect or the other, you tend to treat the other with less focus. That is why there needs to be a balance and the project lead should be responsible for that.
No comments:
Post a Comment