1 |
Ciaran McCreesh wrote: |
2 |
|
3 |
>On Tue, 10 May 2005 22:19:27 -0500 Brian Harring <ferringb@g.o> |
4 |
>wrote: |
5 |
>| On Tue, May 10, 2005 at 09:54:33PM +0100, Ciaran McCreesh wrote: |
6 |
>| > Is there a standard way of handling testing for utility-type |
7 |
>| > eclasses? For versionator I currently have a |
8 |
>| > __versionator__test_blah function included in the eclass (source |
9 |
>| > versionator.eclass works, it doesn't have any portage-specific |
10 |
>| > code), but this is going to get a bit messy when I add in another |
11 |
>| > few dozen tests... |
12 |
>| > |
13 |
>| > Maybe a simple test harness could be added as an option for the new |
14 |
>| > eclass / elib setup? |
15 |
>| Elaborate on the tests... |
16 |
> |
17 |
>Best example I can give are the kind of thing that's in versionator |
18 |
>already. The tests in the updated version in bug 87157 are probably |
19 |
>better than the ones in the tree... |
20 |
> |
21 |
> |
22 |
> |
23 |
A good example on how to do this is given with mysql sources, the file |
24 |
hierarchy look like this: |
25 |
/mysql-sources |
26 |
\_ mysql-test |
27 |
\_ mysql-test-run.sh |
28 |
\_ t |
29 |
| \_ test1.test |
30 |
| \_ test2.test |
31 |
| ... |
32 |
\_ r |
33 |
\_ test1.result |
34 |
\_ test2.result |
35 |
... |
36 |
When the programmer is satisfied from the output from one test he put |
37 |
the result in r/test[n].result . |
38 |
This way it can be diffed and make very easy see the result of every |
39 |
little change. |
40 |
|
41 |
Pros: |
42 |
- Bash is an interpreted language, that must parse the sources files |
43 |
every time, this approach has the benefit that tests related source is |
44 |
keeped separate and so it doesn't waste bash parsing time. |
45 |
- It make easier to create a script that run all the tests, making easy |
46 |
to see the effects of one change to to other eclass |
47 |
|
48 |
Cons: |
49 |
- additional overhead on syncing portage tree |
50 |
|
51 |
|
52 |
-- |
53 |
gentoo-dev@g.o mailing list |