How many of you are Extreme Programmers?
robin at jessikat.fsnet.co.uk
Fri Apr 18 01:42:33 CEST 2003
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.
>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
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
>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
More information about the Python-list