Mechanized testing suite RFC

Mechanized testing suite RFC

Status:	unknown
Sponsored by:	no one
Developed by:	no one
Expected for:	?
Bug number:	Bug 8300
Work in progress repository:
Description:	There should be a set of tests that use Test::WWW::Mechanize to automatically test the functionality of Koha.

Config

The one currently proposed patch using Test::WWW::Mechanize uses environment variables for the information it needs to access the test installation:

To test:
1. Install Test::WWW::Mechanize
> sudo apt-get install libtest-www-mechanize-perl
2. Set environment variables to reflect your Koha instance:
> export KOHA_USER=kohaadmin
> export KOHA_PASS=katikoan
> export KOHA_INTRANET_URL=http://localhost:8080
> export KOHA_OPAC_URL=http://localhost
3. Run the test:
> prove t/db_dependent/www/batch.t

Is this flexible enough? Would it be better to store the relevant information in config files, and then use one environment variable to point to the config file that should be used? That would perhaps make it easier to switch between testing different setups.

Utilities

When writing tests with Test::WWW::Mechanize there are some things we will want to do in most of the tests. We could always use Test::WWW::Mechanize to do what we need, but implementing the same steps over and over in different test scripts would be inelegant.

Here are some things that it would be nice to have utility methods for:

• Logging in to the OPAC and staff client (there should be tests for each of these of course, but each test script should not have to reproduce the steps needed)
• Changing user permissions (to test some functionality with and without the permission to use it, and as superlibrarian)
• Changing system preferences

These utilities could

• talk to the Koha API/modules/database directly, or they could
• be implemented with Test::WWW::Mechanize, and just centralized in their own methods (this would require always having a superlibrarian user on hand for doing the changes, though)

Two kinds of tests?

Would it make any kind of sense to somehow divide the tests in two - those that do not change anything in the database on the one hand and those that do change the database on the other? If the first ones were separated out, they could be used to test live installations (e.g. after an upgrade) where you don't want to insert dummy data.