ahmad sayed <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
pgp6AFACPplOh.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
