Browser based testing on master

Hi all,

On Wednesday, I sent out a note that we have BDD tests on 'master'. What I meant is "browser based testing" for which I chose the BDD style: a user readable script declares the steps in a workflow and the test script verifies if the application conforms to that recipe.

The version I committed to the repository on Wednesday was fully dependent on the UI layout of the application and described the workflow steps in a very instrumentational manner ("if you press this button, you should see 'transaction posted'").

Between Wednesday and today, I converted the initial scripts which were rather lengthy and completely dependent on the looks of the UI, to a PageObject style, where both the scripts are shorter now *and* the scripts dependency on the page layout has been almost eliminated. The scripts are now written in a more abstract manner: if you log into setup application, you should see the (company creation|company admin) page [depending on whether the database already exists or not].

Here's some documentation regarding my inspiration of using BDD with PageObject style coding: http://capgemini.github.io/bdd/effective-bdd/ Check https://github.com/ledgersmb/LedgerSMB/blob/master/t/66-cucumber/01-basic/setup.feature#L1 to see what we currently have for testing of setup.pl.

So the relevant question is: where to go from here?

I'm thinking the following: the tests that are in place at the moment are specifically directed toward setup.pl and are located in the '01-basic' folder. My thoughts about next steps are three-fold:

1. In 01-basic, we'd want to have a app.feature test to accompany the currently existing setup.feature and login.feature. 'app.feature' would do little more than logging in on a test-app,

add some minimal configuration (if required) and run through all the menu items checking that the resulting pages show up and don't generate errors

1(a). in addition the same thing could be done for all search screens, clicking on the Continue/Search button and checking that a valid result comes up.

2. Some of the less experienced coders (but experienced users?) could help write BDD scripts which the more experienced coders can then convert into real tests, building the PageObject foundations required.

3. This is probably the most important one of all: have a test to go with each bug fixed on master(and 1.5, as soon as master becomes 1.5). End users can help here by providing reproduction recipes which experienced users and other contributors can convert into BDD scripts and then the core developers can build the required underlying PageObject infrastructure.

The main question would be: what should we/I do to get these three pillars into operation? I'm doubting a call for participation to the users@ list would be the correct thing to do: we just had one of those for participation in translations (and general project involvement) -- I think a call by the end of the quarter would be much more appropriate.

However, I wouldn't want to wait that long and would like to achieve results on a much shorter term, if possible: I think making progress to define tests is key to releasing (stabilizing) 1.5, which we really want to get "out the door" (without rushing it, of course).

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.