Gnucash UI dogtail test harness some ideas

Josh Sled jsled at
Mon Jun 11 21:10:32 EDT 2007

ahmad sayed <ahmadsayed83 at> writes:

>>> In the complex case of some XML file that was describing the tests more fully
>>> (or even "formally"), that file could contain a whole mini-language for doing
>>> test Setup ...
> I always prefer to use XML at its descriptive level, xml o describe some
> thing, which will be what this test case are going to do in formal
> describtion, and which method in the python code do it, maximum complextity
> i intend to add is to add keywords, to control which test cases to run like
> run all testcases that marked as smoke test, all run the whole regression,
> i didn't have a wide experience but i see this practice in the GUI test

Ah, the keywords are interesting, but I wonder if they could be done another
way ...  in any case, I'm not sure that we need keywords or grouping of
tests.  I note that we don't have anything similar for `make check`,
presently.  I think I'd rather that we have so many tests that we feel like
we need a way to only run subsets of them, than to engineer this in up-front.

> suites, the other complexity i expect to add is to make this XML, is
> putting the test case data in this xml, which will be we have more than one
> test case in the testplan file but all of these test cases call the same
> python method with different data.

Ah, but this too can be accomplished in code, with about the same number of
lines of code as an XML version... e.g.:

    def _test_core(arg1, arg2):
        res = do_the_thing();
        assert(, arg2)

    def test_none():
        _test_core(None, '')

    def test_empty():
        _test_core('', '')

    def test_boundry_case_bar():
        _test_core('bar', 'baz')

>>> Even in the simple case, the XML file is just a re-iteration of all the test
>>> functions (or methods, whatever they are) that already need to be specified
>>> in the code.
> I really liked this, but this make writing the test plan part of the code which is good with unit testing.

Can you rephrase, please?  I don't follow you.

>>> How much of this validator would be custom work vs. being provided by
>>> dogtail?
> It will be a custom work, yes dogtail dump the node data, in both plain and xml format but its dump method is very obvious and limited so it will be a custom work.

Ah, that's too bad.  I'd have imagined that dogtail can dump in sufficient
detail to do useful diffs with.

ahmad sayed <ahmadsayed83 at> writes:
> 3 - How could i get a dev account to be able to commit the current code i
> have to the svn. i got the i'm going to have a branch in which i'm going to
> commit my updates, what should i to make it happen

You need to generate an ssh key-pair, and send the public half, along with
your preferred username, to Derek.  As well, we need a branch-name; I think
'dogtail' is suitable...?

...jsled - a=jsled;; echo ${a}@${b}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : 

More information about the gnucash-devel mailing list