[dev] automated tests Was: Help with attachments

[Jan Schneider]

Zitat von Eric Rostetter <eric.rostetter at physics.utexas.edu>:

> 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.

Yes, automated test don't make much sense to me, but having a simple test
framework and do some basic checks at login sound good.

> 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)

This could be done with the cvs commit scripts on the server side. IIRC Jon
mentioned something like this in the past.

> * catch/report violations to CODING_STANDARDS

This would be a bit harder, but is basically done during the "pear package"
command. I think we could take some ideas from there.

> * automated scripts to test stand-alone library functions (like
> encryption
>   functions, compression/decompression functions, etc)

See lib/Data/tests that was a start for exactly such a test framework,
powerd by "pear test".

> 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?

Yes, but please look at what's already there, so that we don't reinvent the
wheel.

> 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...

Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft