Re: Running BDD tests (on 'master')

Hi David,

As discussed on IRC, I'd send you instructions how to run the BDD tests on master.

The Perl prerequisites are easy: those get installed using "cpan --install-deps ." or "./Makefile.PL && make". Additionally, you need to have a copy of PhantomJS running. I downloaded my copy for 1.9.8 here: https://bitbucket.org/ariya/phantomjs/downloads/. Then you have to have a PostgreSQL cluster installed for use with LedgerSMB, with a superuser which can log in using a password.

Might be worth listing what capabilities the superuser needs. it it just createdb, createrole, and login?

Actually, I was thinking a real "PosgreSQL super user" (which has all of the above by virtue of being a super user). The minimal requirement for a LedgerSMB setup.pl admin would be to have createdb, createrole and login indeed.

You need to get all the services running with these steps:

$ phantomjs --webdriver=4422

And in a different window:

master$ starman tools/starman.psgi

and in yet a different window:

master$ PGUSER=<your-super-user> PGPASSWORD=<your-superuser-password> LSMB_BASE_URL="http://localhost:5000" pherkin t/66-cucumber/01-basic/

This looks like a candidate for a script that starts up a tmux session with each required command in a separate window.
(I don't recommend screen anymore as it is essentially unmaintained while tmux is actively maintained and is *almost* the same as screen)
I'll see if I can whip that up shortly.

Sounds like a nice step. Although during development, I keep all these windows open and re-run the pherkin command time-and-time-again. For the more occasional user, it seems good to have though, even if it only serves as "example code".

The pherkin command creates a user "the-user" and a database "non-existant" in your cluster. If you want to repeat the pherkin command, please make sure to delete these entities before doing so.

Note: of course this is due to be improved, however, at the moment this is what's there. (I'm working on a PR for Test::BDD::Cucumber to allow post-testing hooks/triggers which we could use to delete the roles and databases created during a test-run.

Rather than post testing hooks for this, I think they should actually be pre-testing hooks.

Good point. I think we want the post-hook to clean up when everything went fine, but leave it all in-place for developer-inspection when there were failures. The pre-hook should delete or create and overwrite to make sure the test can complete without problems regardless of left-overs from previous runs.

That way the database and user stay available for manual investigation post test.
Perhaps if all tests pass a post-test hook could remove them, but either way, if they exist, a pre-test hook should remove them.

The existence of the user and DB created shouldn't present as a problem for normal systems as long as the tests drop them before running so they can probably hang about for ever.

Ok. True, but I like to leave things behind cleanly, if there's a possibility to do so: we're probably not running on a dedicated cluster, so people will want to continue using the cluster and probably want a relatively clean environment to work with.

Bye,

Erik.

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

Robust and Flexible. No vendor lock-in.