Ciaran McCreesh wrote:
>On Tue, 10 May 2005 22:19:27 -0500 Brian Harring <[EMAIL PROTECTED]>
>wrote:
>| On Tue, May 10, 2005 at 09:54:33PM +0100, Ciaran McCreesh wrote:
>| > Is there a standard way of handling testing for utility-type
>| > eclasses? For versionator I currently have a
>| > __versionator__test_blah function included in the eclass (source
>| > versionator.eclass works, it doesn't have any portage-specific
>| > code), but this is going to get a bit messy when I add in another
>| > few dozen tests...
>| >
>| > Maybe a simple test harness could be added as an option for the new
>| > eclass / elib setup?
>| Elaborate on the tests...
>
>Best example I can give are the kind of thing that's in versionator
>already. The tests in the updated version in bug 87157 are probably
>better than the ones in the tree...
>
>
>
A good example on how to do this is given with mysql sources, the file
hierarchy look like this:
/mysql-sources
\_ mysql-test
\_ mysql-test-run.sh
\_ t
| \_ test1.test
| \_ test2.test
| ...
\_ r
\_ test1.result
\_ test2.result
...
When the programmer is satisfied from the output from one test he put
the result in r/test[n].result .
This way it can be diffed and make very easy see the result of every
little change.
Pros:
- Bash is an interpreted language, that must parse the sources files
every time, this approach has the benefit that tests related source is
keeped separate and so it doesn't waste bash parsing time.
- It make easier to create a script that run all the tests, making easy
to see the effects of one change to to other eclass
Cons:
- additional overhead on syncing portage tree
--
gentoo-dev@gentoo.org mailing list
