Re: Testing the case against XP

[Jerry Jackson <address@hidden>]

Steve Dekorte wrote:

> 
> On Thursday, May 15, 2003, at 11:25 AM, R. Clayton wrote:
> 
>>   Jerry -- I'm confused. How do you write unit tests say for the 
>> Travelling
>>   Salesman Problem :)
>>
>> Ah, but don't you see - you're illustrating his point (if even in 
>> jest).  The
>> very fact that you're confused about writing a test case should lead you,
>> eventually, to the possibility that your attempt to include the TSP as 
>> part of
>> the solution is perhaps not the best approach to take.
> 
> 
> As he noted, UIs and data driven apps have the same problem(of test 
> coverage being minimal at best). Must those approaches be abandoned in 
> order to use your methodology?
> 


As I mentioned before, some types of apps are harder to test than others
but not impossible.  Our web GUIs are tested using HTTPUnit and have
pretty good test coverage.  The GUI developers follow the same model

as everyone else.  A direct manipulation interface might

be tougher to test but that's a general problem with that kind of
app.  Surely you wouldn't give up on testing a GUI because it's
difficult?

Data driven apps can usually be approached via mock data sets and "mock
objects" in general.  (The mock object technique is an adjunct to TDD
that is interesting in its own right -- See: http://www.mockobjects.com/)

In general, the coverage question is addressed by the "try to break the
app" approach.  When a knowledgeable developer can no longer come up
with a scenario that breaks the app, declare victory and move on (assuming
that we're talking about one of these "hard" domains and we can't expect
to get information from a coverage tool).

Something that I haven't seen mentioned much in this discussion is that 
with TDD, the
code is simply much better tested.  This means a lot.  I've been coding
for a long time (I'm 43 and started in high school).  I've spent a lot
of time doing requirements/specs/designs and trying to get the code right
up front.  There are _always_ bugs. (I'm unfortunately one of the
few imperfect coders on this list :-)  What usually happens is that a
tester who has far less understanding of the code than the developers
is stuck with the task of writing tests for it.  A tester is simply not
in nearly as good a position to figure out how to break the code so a
lot of problems sneak through.  I know the subtleties and corner
cases of my code and I can write tests to exercise them.  (At least,
I do when I'm writing it.  No guarantees when I go back to look at
it a few weeks/months later -- another reason for writing the tests
as part of the development process).

Regards,

--Jerry