Testing tools
Cédric Krier
Following a talk I had with udono about testing. I want to share my idea for
more testing in Tryton.
First, we need to add more and more unittest for trytond and after for every
modules.
Second, we need to have scenario testing. I think pycukes [1] could be a good
solution.
End last (but not least), we need to test the GTK client. I think this tool
could be a good way: LDTP [2] but it needs some check to see if it can work
with Tryton client.
I think our priority must be the unittest.
[1] http://pypi.python.org/pypi/pycukes/0.1.1
[2] http://ldtp.freedesktop.org/wiki/
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email: cedric...@b2ck.com
Jabber: cedric...@b2ck.com
Website: http://www.b2ck.com/
Udo Spallek
Am Sonntag, den 01.11.2009, 13:05 +0100 schrieb Cédric Krier:
> Following a talk I had with udono about testing. I want to share my idea for
> more testing in Tryton.
>
> First, we need to add more and more unittest for trytond and after for every
> modules.
> Second, we need to have scenario testing. I think pycukes [1] could be a good
> solution.
Scenario testing looks very interesting. Yesterday I followed a post at
tinyerp with exactly this topic, but realised upon Rubys cucumber[3].
With this we could narrow the step from using Tryton to testing Tryton,
since it reads like 'natural language'. The accessor mehods needs to be
written by develoters, but the final testcases could be written by
'trained' users. Test scripts would look like:
Story: Accounting
As an accountant of an enterprise
I want to book bills and receipts
So that my company follows all national legal terms
Scenario 1: Enter a Phone Bill
Given I have a phone bill
When I enter the phone bill
Then the phone bill is accepted as draft phone bill
Scenario 2: Check the income statement
Given I entered some bills
When I check the income statement,
Then the income is lowered by the amount of the bills
...
> End last (but not least), we need to test the GTK client. I think this tool
> could be a good way: LDTP [2] but it needs some check to see if it can work
> with Tryton client.
This tool needed to have an accessibility enabled Tryton. So I think it
is Linux only and maybe Gnome/KDE only.
Dogtail[4] I evaluated last year for some hours. But it needs
accessibility enabled, too.It worked with tryton (and accessibility
enabled Gnome). The only lacks are missing ids for each Tryton widget to
identify in a view.
Visual GUI testing approach sounds perfect. Just record and click your
test cases together and save the autogenerated script as a ready to use
test case, thats it. But is it for real this easy?
For me it is a question if we really need visual GUI Testing? Since we
always re-use self made high level widgets in Tryton, we could provide
unittest cases for the client which test the API/widgets of the client.
Another possibility is to provide a client_test module, which generates
general examples of all Tryton widgets, Signal handling and common
combinations. The testing could be half automated, by using the general
widgets in the client and reporting bugs.
If there are additional problems in views which are module generated,
then these problems will be mostly in the logic- and data layer and
handled via unittests or scenario testing.
My goal is, that I like to test logical stuff like this:
>From a propritary software I generate exports of a business year of a
company with all product, prices, taxes, invoices, parties, reports etc.
This data I like to push into Tryton and want so check if the reports
and values are all the same.
It seems that your proposed scenario testing could be a better
compromise between documenting what you test and testing then pure
unittests. But it is clear, under the hood both approaches are unittests
and needed to be coded.
Anyway, scaling the possibilities of testing Tryton up for higher level
test I absolutly recommend.
Cheers Udo Spallek
> I think our priority must be the unittest.
> [1] http://pypi.python.org/pypi/pycukes/0.1.1
> [2] http://ldtp.freedesktop.org/wiki/
[3] https://launchpad.net/oerpsenario , http://dev.camptocamp.com/files/operpScenario/result.html
[4] http://www.redhat.com/magazine/020jun06/features/dogtail/
--
____________________________________
virtual things
Preisler & Spallek GbR
Munich - Aix-la-Chapelle
Windeckstr. 77
81375 Munich - Germany
Tel: +49 (89) 710 481 55
Fax: +49 (89) 710 481 56
Udo Spallek
I remember and re-found another tool, which I tested last year, called
gtklogger[5]. I like the aim of gtklogger a lot, because it catch two
approaches: transparent GUI testing and user side macro recording.
Gtklogger is mainly a logger for gtk events and signals, which are
stored in a file. This file can later re-played into the software, like
a macro recorder/player. The recorded file is general a python like
file, which is evaluated line wise (blocks are not allowed) in addition
with some keywords. So you can modify code inside the script.
This software doesn't need to have accessibility enabled, but some
changes in the source code. Good documentation available[6], too.
Anyway we need to change the source code for the client, to identify the
single widgets, equal which Gui testing tool we use. The good side on
gtklogger is, that we can handle trytons higher level widgets like they
are: A one2many is one higher level widget and not an entrybox + three
buttons + table + a lot of signals.
[5] http://www.ctcms.nist.gov/oof/gtklogger/
[6] http://www.ctcms.nist.gov/oof/gtklogger/docs/gui_testing.pdf