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.
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
