Introduction

The context in which code is being executed, changes all the time: new features are being added and existing callers refactored or (bug)fixed. As the author of a feature you'll want to make sure that the feature works correctly to start with, but even more, you want to make sure its behaviour remains dependably stable.

Generally its a lot of work (but doable) to develop a new feature and test its operation by hand -- especially if only for the limited scenarios the author needs it for. To make sure that all features ever added (and all those yet to be added), keep working reliably on each change being committed, is way too much work. When submitting a new or changed feature, we need to take that into account by developing test infrastructure to assert correctness with.

There are more benefits to developing tests:

• In case the development of the feature turns out harder than expected, the investment in automated tests might already pay back on the initial development
• Thinking about the scenarios to test before or while coding the feature helps to assess the impact on the rest of the code base
• Well tested code has a (much) lower bug-rate

Tests generally need to be developed for each feature on various levels, as is the code that's being developed for a feature, change or bugfix:

• Database (stored procedure) level
• Perl API level
• JavaScript widget API level
• Web Service level
• Web application level

The sub-pages of this page document the infrastructure in place to validate code correctness on the various levels.

General infrastructure

The LedgerSMB project uses the "prove" utility as its test driver: it has a huge number of features for test planning (parallel testing, failed-during-last-run-only, slow-tests-last, etc) as well as extensibility to add test capabilities by using plugins. Plugins to "prove" are used to add testing capabilities (on top of the standard Perl code testing capability):

• (PL/pg)SQL testing through pgTAP
• BDD/WebUI testing Test::BDD::Cucumber (a.k.a. 'pherkin')

The pgTAP tests depend on a PostgreSQL database server being available.

The BDD/WebUI tests additionally depend on a running Selenium server (e.g. PhantomJS) and a running LedgerSMB web application server.

This infrastructure is a lot to set up oneself. There are two ways to get started quickly without the need to install all the dependencies manually:

1. Use the Docker development image from Docker Hub: dev-master
2. Use Travis CI to test your changes - the repository holds a '.travis.yml' file to run tests on their infrastructure