[dev] RE: [imp] Help with attachments

Eric Rostetter eric.rostetter at physics.utexas.edu
Mon Jun 9 13:24:10 PDT 2003


Quoting "Roger B.A. Klorese" <rogerk at queernet.org>:

> > I'm not sure what a 12 to 24 hour schedule buys you.
> > Certainly not enough time to catch most bugs (though it might
> > catch simple typos, changes you later revert, etc).
>
> With automated smoke tests, it adds a lot.

Any interest in adding some 'automated tests' to the Horde project?

I really can't see were we can achieve the desired goal of Roger, which
I guess is to make "automatted smoke tests" which will ensure each
build/snapshot actually works, what ever that would mean in the context
of Horde...   For this, I think we would need non-automated smoke tests.

But maybe we can gain some slight stability from such simple, automated
tests?  Or at least find simple errors sooner?

Any ideas on implementing automated tests for Horde, to make better snapshots,
or just to help catch simple mistakes?  Some ideas I can think of that would
be very basic are:

* "lint" the repository for syntax errors (run "php -l" on all php files)
* catch/report violations to CODING_STANDARDS
* automated scripts to test stand-alone library functions (like encryption
  functions, compression/decompression functions, etc)

I'd be willing to write something up for the first two at least, and run
it on a regular basis, only because it could also be of use to me in my
other major project I'm working on.  Is there any interest in my trying
to do this kind of thing?

Obviously any automated tests will be very limited and not provide
a lot of help, but they may be of use for some of the more simply errors
we repeatedly make.  In addition, perhaps we can make a hand-test doc
(list of things to test) for new releases to be followed (say for
the release candidates) to make testing more regimented?  I've seen a few
short lists in some modules, but something concrete for each module (these
are the things we must test and must pass before we release the code) might
be a useful guideline to have for each app.

Just tossing the ideas out (based on Roger Klorese's postings) to see if
there is interest.  Like I say, I'm willing to try to code up some simple
tests if others are interested in me doing so...

--
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Why get even? Get odd!


More information about the dev mailing list