It has come to my attention that Extreme Programming is the subject of some religious coding wars. Apparently, there are extreme Extreme programmers. Anyway, I've been using XP for a couple of years now and there a re some rules of thumb we've developed:
When you write a test, it should fail.
There are proponents for 100% test coverage, but that's not where we aim. Tests are there to drive development, so each new test when written should be trying to do something the system can't currently do - hence it should always fail, you write the code, it should succeed.
Test the behaviour, not the implementation
I'm using Google Test & Google Mock as my testing setup. It has a very odd syntax which the documentation encourages, where you can specify how many times you expect a given function to be called. Duh huh? Why would you give a monkeys about that, as long as the overall function gives the desired result? Using this will result in highly implementation dependent tests, and that means highly brittle tests that will fall over when you change your design in the slightest. Better to write a test along the lines of 'If you ask a unit to move to a given location, the unit moves to that location', rather than something in terms of function calls.
Make code general the second time you use it
An extension of the normal XP principle of not doing something until you need to. Don't waste time refactoring your code to be re-usable until you definitely find you're about to re-use it.
Pairing is not always necessary
Let's face it, a lot of coding is pretty straightforward. There are times you do by hand what a macro could accomplish, but it's not worth writing the macro for the time you'd save. In cases like this, you don't need to pair because you're not doing any thinking. Save the effort and let someone do it on their own. Minor refactorings and tidying up the appearance of the code also come into this category. It's often handy to keep a pile of these 'single programmer' tasks handy, as you don't always have an even number of people available, and that odd-man can't make tea all day.
There are more, but that'll do for now. The
Saturday, 12 December 2009
Subscribe to:
Comments (Atom)
