Eric Kow wrote:
Test-driven development : a new way forward?
============================================
Show me concretely how you use automated testing to manage the
transition from this slurp code we've been using for years to the new
shinier code.
I don't develop 100% Test Driven, especially UI is my weak point. But
with TortoiseDarcs, I saw no alternative.
Here's reason why it's important: If there's ANY difference in darcs
behavior in the currently five configurations I support, I want to find
it right away. Here's a sample how things can quietly change:
darcs1 query manifest
./last\32\added.txt
darcs2 show files
./last added.txt
So space encoding in filenames changed from version to version. Not a
problem, if you find it before release.
Here's my main data driven test:
const ExpectedFileStatus files[] = {
{"", DarcsStatusFlags::STATUS_OUTER_DIRECTORY},
{"added file.txt", DarcsStatusFlags::STATUS_ADDED},
{"alice.txt", DarcsStatusFlags::STATUS_IN_DARCS},
{"bob.txt", DarcsStatusFlags::STATUS_IN_DARCS},
... 42 files and directories altogether.
Multiply with options (allow stale statuses / force status computing)
and with five pristine options you have 420 files to check over and over
again, every Tortoise release, every Darcs version. There's no
alternative to automation.
The python script that creates these test repositories is now 230 lines,
and it has grown frequently.
This isn't even so extreme. I have less unit tests than code, which is
unusual when it comes to my libraries. One reason is, that the only call
I really care about, StatusDB::GetFileStatus(filename) is so simple.
With more complex interfaces test code usually becomes bigger.
I don't remember when I had to debug the actual shell extension last
time. When starting the development, I just started with a few statuses,
made them work and it was done.
Kari
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
