I'd like to share this page with people who, for whatever reasons, have been unable to adopt all of XP's practices in one go, but who are migrating towards it in whatever increments they've found possible.
I went for UnitTest
s first. In our engineering group (15 of us), nobody did any sort of unit testing. Code here has always been tested at the integration phase using test clients/servers and a debugger. Over the last six months I introduced UnitTest
s using a C++ version of JavaUnit
(which I worked on and enhanced) and three of us are now using it successfully.
My evangelising of UnitTest
s to other engineers has received a generally lukewarm reception. Their basic objection has been the time involved in writing these tests. I know the arguments, but arguments are just words. They will need to see how my team's better tested software succeeds in the long term before they become convinced.
The two people on my team who I effectively forced to take on UnitTest
s are, they assure me :-), converted. I note they still prefer to do the older TestingByPokingAround
first and I think that if they had to drop one of the two ways of testing they would go back to what they'd used before.
My boss likes the UnitTest
s because they give him a measurable level of confidence in the software (we achieve about 92-93 % code coverage) which he just can't get with ad-hoc testing.
So all in all with UnitTest
s, a good start, but still some way to go.
ing became possible once we had sufficient UnitTest
s to ensure good code coverage. I wouldn't say we have RelentlessTesting
at present, and it's still possible for ReFactor
ing to break code because not all of our code tests are captured by our UnitTest
s, however we have enough confidence that we ReFactor
with only a little bit of worry.
ran me up against the problem that engineers need to know that they can do the task by themselves (IndividualAchievement?
). I backed away from this to a strategy of frequent code reviews, even rewriting code that I wasn't happy with. This sort of made me a co-writer of some of our software which led to CollectiveCodeOwnership
, an XP practice which I am generally winning with vs the objection "I work better when it's my baby" (IndividualCodeOwnership?
We did a BigDesignUpFront
, but it wasn't that big. In summary I would say we followed the design, code, test cycle over a 3-4 month period, and that became our first iteration. Then we continued iteratively with UnitTest
s and ReFactor
ings. We did do some DesignDocumentation
, enough to give us a road map (highest level abstraction) on our software.
I started with UnitTest
The way I have found works best for me is to just start doing it myself. As other developers ask questions, they find out what I am doing. As they look at my code, they see my tests. As we pair (to solve individual problems - we are not at the PairProgramming
stage yet), they see how I work. Test first. Then code. We end up working less (read as writing less un-useful code). Nobody else has started using them but they all saw the point of the tests and agreed that they were useful. Maybe the question should be WhatStopsUnitTesting?
I also stress repeatedly that we should do the simplest thing. This leads to the idea of ReFactor
ing very nicely. The latter follows the former logically. It is
difficult to explain ReFactor
ing unless you can actually show it in action. Some of the ReFactor
ings I do on a daily basis (MoveMethod
) look very simple and people don't see it as ReFactor
ing. Developers look for a silver bullet and are disappointed when there is none. Maybe the best thing would be to do PairProgramming
before worrying about teaching others to ReFactor
. It's just too hard to explain without concrete examples. When people are paired then it should be easier for the driver to show his partner what ReFactor
ing is and how it works.
The other day I had a great reaction to CrcCard
s. We discussed the basic architecture a bit and I started writing class names on some index cards I had with me. By the time I started to add responsibilities the others were passing the cards around to see what was written on them. When we split up we just divvyed up the cards (and I didn't even have to mention that we should - one of the other guys just grabbed some of them and said "Okay, we'll do these ones and you do the others.")
I have had the same experience that when index cards are used, people adopt them very quickly. I think this is a great example of DoTheSimplestThingThatCouldPossiblyWork
. Its a change from the top down. I think the resistance to Unit Testing is largely because it is a bottom up change, and the developers feel they are being made responsible for doing something they haven't volunteered or wanted to be involved in.
I think the other resistance to testing comes from the fact that most people don't know where to start. Which tests should I write? In programming, normally people pick an arbitrary start point, something they know how to do already, and just code from there. Maybe having people pick their start point, then writing the name of the test on the index card might help? Then they know their goal. I think this is the key:
Make the goal of development 'Having your tests pass' not writing lots of code. Form the project goals, rewards and milestones around that. This is where the cards and 5 minute meetings would come in helpful. Change the focus from writing lots of code to (workingless). - Todd Edman