Gnucash UI dogtail test harness some ideas

[Josh Sled]

ahmad sayed <ahmadsayed83 at yahoo.com> 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):
        act_on(arg1)
        res = do_the_thing();
        assert(res.foo, 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 yahoo.com> 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
http://asynchronous.org/ - a=jsled; b=asynchronous.org; 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 : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20070611/7b8792b7/attachment.bin