Am Sonntag, den 01.11.2009, 16:45 +0100 schrieb Udo Spallek: > Hi, > > 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.
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. > 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/ [5] http://www.ctcms.nist.gov/oof/gtklogger/ [6] http://www.ctcms.nist.gov/oof/gtklogger/docs/gui_testing.pdf -- ____________________________________ 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 [email protected] http://www.virtual-things.biz --~--~---------~--~----~------------~-------~--~----~ [email protected] mailing list -~----------~----~----~----~------~----~------~--~---
