# from JT Moree
# on Friday 06 April 2007 09:49 am:
>I'm guessing--since you mention this multiple times--that there is no
>test suite for dirvish?
Correct. Combine that with the lack of modularity and the $Options
variable as a global (plus a few other issues) and it becomes very
difficult to ensure that adding a feature hasn't broken someone else's
use case. It's also very difficult to do any sort of refactoring.
For example, just verifying that the rsync command line is correctly
formed would be a good step. Let's say you get a big pile of config
files, and then override CORE::GLOBAL::system(), looping through them,
possibly with "local @ARGV = ..." before "do('bin/dirvish.pl')" or
something similarly painful. Your overridden system() would collect
the @_ into a variable which the tests would is_deeply() against some
previously generated static data keyed to each (set of) config file(s).
Now, that's going to be an ugly and possibly difficult to grok test.
But, it does give us *something* that isn't affected by system
configuration (except things like loadconfig() recursion hitting the
filesystem, but presumably that could be dealt with.) Note that I
haven't even started writing it and there are already corner cases to
be handled. Most of the complication of dirvish is currently nested
into anonymous subroutine callbacks which have various runtime affects
on global variables based on config-file, command-line, or filesystem
states. If anybody wants to tackle this, I wish you luck.
Another testing approach would be to build some sort of chroot/vm
virtual network and actually run the thing, monitoring the behavior
externally. This is maybe simpler in that it doesn't require you to
override every CORE::GLOBAL function because side-effects on the
filesystem *are* desirable (they are essentially the test output.) It
does require a lot of world-building (which can be distributed to other
developers, but will take quite a bit more setup on each machine and
will likely involve a large volume of data) and the tests will take
longer to run.
Of course, the original "install system" sheds some light on why there
is no test suite. The architecture (if you could call it that) doesn't
really lend itself to unit or any other sort of internal testing. The
programs didn't even exist in their full form until after install.sh
was run (though they're not being directly concatenated
into /usr/local/bin, they might as well have been.)
for f in $EXECUTABLES
do
echo "$HEADER" >$f
cat $f.pl >>$f
cat loadconfig.pl >>$f
chmod 755 $f
done
no use() or require() needed :-D
--Eric
--
"Matter will be damaged in direct proportion to its value."
--Murphy's Constant
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
_______________________________________________
Dirvish mailing list
[email protected]
http://www.dirvish.org/mailman/listinfo/dirvish
