Quoth Ryan Schmidt <mailto:subversion-2005@ryandesign.com>:
> 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.
The main thing you need to do to make life easier is to reduce coupling
in your code. Make sure each class only has one responsibility, and use
abstract interface patterns to disconnect classes, so that you can "mock
out" other classes and test each class in isolation (in addition to
testing interaction between classes).
Also make sure that each method only has one responsibility, and keep
them short. The general rule of thumb is that if it doesn't fit on a
single screen, then it's too long (and probably trying to do too much)
and ought to be refactored. This not only helps code readability, but
also gives you smaller pieces to test.
For example, for your daily currency conversion rate importer, you could
have one class that's solely responsible for downloading the file from
wherever it is kept, and a different class that then parses that into
some meaningful objects, and a third class that schedules the other two
on a daily basis. That way you can test the parsing entirely divorced
from the downloading, and vice versa.
---------------------------------------------------------------------
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:57:04 2005