How many of you are Extreme Programmers?

[Robin Becker]

In article <Xns9360989556563duncanrcpcouk at 127.0.0.1>, Duncan Booth
<duncan at NOSPAMrcp.co.uk> writes
>Robin Becker <robin at jessikat.fsnet.co.uk> wrote in 
>news:XiCE$IAjFmn+Ew43 at jessikat.fsnet.co.uk:
>
>> I get the impression that XP is intended as a design none/test all
>> process where the code some grows organically into the requirement
>> through bursts of coding and testing. It even seems as though the
>> testing is primary.
>
>XP ranks design very highly. Its just that it recognises that coding is an 
>aspect of design. 'Big design up front' thinks design is something you do 
>once before you start coding, XP thinks that design is continuous 
>throughout the process.
.... interesting
>
.........
>What makes test driven development so powerful is that you write the 
>specification while thinking about WHAT the code has to achieve. If you 
>write the test after the code you are inevitably thinking about HOW the 
>code achieves its results. Writing the test first means your tests relate 
>to the specification rather than the implementation.
>
>You are correct to some extent, if the programmer didn't think of 
>particular cases when writing the tests, then XP almost demands that the 
>code doesn't support those cases. In particular, deliberately writing code 
>that fails on all data other than the tested data is a common way to do 
>TDD: Write a test, make sure it fails for the expected reason, then write 
>minimal code to make it pass (which might involve hardwiring the result), 
>make sure the test passes, refactor all the while making sure all tests 
>still pass.

so we have terms in the utility which penalize rather than benefit.

>
>The refactoring stage is the one that (hopefully) renders the code as short 
>and clean as possible, which includes removing special case results and 
>making the code support the general case.
>

this is like a secondary utility or cost function ie amongst candidates,
which are equivalent in primary terms, we prefer candidates with better
secondary costs.

>If later in the process you discover a case that you overlooked, then it is 
>a simple matter to add a test for the new case and modify the code to 
>support it while being sure you aren't breaking other cases.
>
Each test covers a subset of the possibilities. I guess the difficulty
is in ensuring that the tests cover a sufficient volume of them (ideally
all) and that the tests give the right answers for each of those
covered.
-- 
Robin Becker