Ryan Schmidt wrote:
> I'd also really like to understand how to actually use such tests to
> support my development. I certainly understand that if I have a
> function multiply() which takes two arguments and multiplies them
> that I can write a test which feeds the function 6 and 7 and checks
> to make sure the answer that pops out is 42. I'm not writing
> functions like that, though, and I don't know anybody who does. I'm
> part of a team writing, among other things, a CRM system for a
> customer doing business in 16 countries. Perhaps the bug of the day
> is that the daily currency conversion rate importer didn't work. Or
> perhaps when we turn on our SQL debugging functions, then the search
> results are wrong. Or perhaps the column headers in Italian are too
> long so they wrap to the next line and mess up the layout of the
> generated PDFs. These are all things that have actually happened in
> this project, and I'm unclear how I would write a testing system that
> would have prevented any of it.
Warning: I'm not an evangelist or even well-read on the topic, but I
can relate it to how I've used it when I've had the chance.
One key thing is that if you design the software with testing in mind,
you tend to break down and modularize the software to a higher degree,
so a single function/method/whatever tends to be shorter and have fewer
branches in it, breaking the complexity out into separate
functions/methods/whatevers. You then have separate tests for each of
the fragments broken out.
In the end, rather than trying to test a single function for every
conceivable input you might pass it, you just need to make sure that it
can handle any given type of return from the lower levels and that all
the paths through itself get tested. You then have separate tests for
the lower level routines. This tends to reduce the overall number of
tests you need to run and makes it easier to come up with the relevant
test cases.
Yes, there are times when test cases are hard to design due to the
nature of the return (making sure that xhtml/css displays properly in IE
and FF, for example), and if it's the kind of software that makes
determining all the failure cases difficult, then it won't add as much
either. However, ultimately, all computer programs break down to a
series of steps that when looked at in small enough groups, are quite
predictable as to what a failure condition is and what might cause one.
I don't think unit testing is something that works miracles, but it
certainly helps in the cases I've seen it used. The only project I've
wanted to use it for that it wouldn't help was because the design of the
system was so poor that you couldn't test anything without involving
most of the system.
Anyway, this is OT so I'll shut up now.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 5 22:38:55 2005