# from Eric Mountain # on Thursday 12 April 2007 02:02 pm: >(3) "qualification" ? tests: this is where "test > machines/environments" can come into play - end to end tests etc. On Thu, Apr 12, 2007 at 10:53:55PM -0700, Eric Wilhelm wrote:
> It should be possible to fake a dirvish config/vault in temp directories > and actually run it. The trouble is partly that the config isn't > (AFAIK) easily writable (e.g. yaml.) Though even simplistic templating > would be enough to set it up in temp dirs. > > This might not catch some issues related to roots, cross-device options, > etc, but it would probably get pretty decent coverage of "rsync runs", > "the tree is ok", etc. Take a look at some of the stuff added 1.3.1 intended to help testing. For example, the config file was settable on some of the dirvish apps, and so I extended that to all the apps. In general, I tried to make all the apps accept the command line options of any of the apps (where relevant), by sharing common code, without changing their behavior without the extra options. I believe this is related to "polymorphism", a technique used in "refactoring". I use both terms in quotes because I'm not sure I am using them right. I understand "refactoring" to mean changing the guts without changing the external behavior, which is what I am hoping we can do. However, I also want to add functionality for test, so that probably isn't described by simple refactoring. The rsync app is chosen in the dirvish.conf file, with the "rsync:" and "rsync-client:" options. By repointing the config file during testing, a fake rsync can be used, which is probably a simple script that tests input and spews appropriate output, without using the network or changing the file system. While we should have a form of "unit testing" that bypasses rsync, users with dirvish problems don't care too much whether the fault is in the Perl code or in rsync. Dirvish relies on rsync as a component, and Perl as a component, and some Perl CPAN modules as components, and if we want our test to claim that dirvish is functional, we should take responsibility for testing some aspects of those components. If nothing else, we should find out if some aspects of rsync are misbehaving during install testing, and let the user know they should be using a different version of rsync that fixes the misbehavior. A complete set of install tests will make sure that the dirvish Perl code delivers the proper command line to rsync, and fail the tests if it does not. But it will also make sure that rsync (and ssh if used) are also working properly, and if not provide some clues to the user to help them fix the problem. "Not my problem" is an attitude that can get a program (or a programmer) replaced by something or someone else that takes more responsibility. I hope this can all be done in a series of fairly simple toy environments. Until we define a fairly complete set of these toy environments, I suspect we will be relying on individuals to do some of the final tests manually, in an ad hoc and nonrigorous way. The need for ad hoc testing goes away when the toy environments and automated tests are complete, but right now all I see are people talking about it, but not taking responsibility for doing it (and I am afraid that includes me). So, either somebody volunteers to writes the automated tests, or a bunch of somebodies volunteer to test new versions manually, or we are overly cautious about adding features that might break something else. Volunteers? Keith -- Keith Lofstrom [EMAIL PROTECTED] Voice (503)-520-1993 KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon" Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs _______________________________________________ Dirvish mailing list [EMAIL PROTECTED] http://www.dirvish.org/mailman/listinfo/dirvish
