89 lines
3.5 KiB
Markdown
89 lines
3.5 KiB
Markdown
# Test organization
|
|
|
|
## Testfolders
|
|
|
|
Tests for the application can be found underneath the test folder:
|
|
|
|
test/
|
|
php/ PHPUnit tests for backend code
|
|
regression/ PHPUnit regression tests
|
|
|
|
The same structure applies for modules, which also contain a toplevel test folder and suitable subtests. When you fix
|
|
a bug and write a regression test for it, put it in 'regression' and name it %DESCRIPTION%%TicketNumber% (myBug1234.php)
|
|
|
|
## Running tests
|
|
|
|
The tests can be run in the specific folder using the runtests script.
|
|
|
|
Running PHP tests example:
|
|
|
|
cd test/php
|
|
./runtests
|
|
|
|
In this case, all application and all module tests will be executed. The testrunners also support additional flags, which
|
|
affect they way the test is executed:
|
|
|
|
Options:
|
|
-h, --help show this help message and exit
|
|
-b, --build Enable reporting.
|
|
-v, --verbose Be more verbose.
|
|
-i PATTERN, --include=PATTERN
|
|
Include only specific files/test cases.
|
|
-V, --vagrant Run in vagrant VM
|
|
|
|
Some tests also support the --exclude method, it's best to use the --help option to see which flags are supported.
|
|
|
|
|
|
## Setting up databases
|
|
|
|
Despite running most of the tests should work out of the box, a few specific cases require some setup.
|
|
At this moment, only database tests require additional setup and expect an icinga_unittest user with an icinga_unittest
|
|
database to exist and have rights in your database.
|
|
|
|
### The database test procedure
|
|
|
|
When testing PostgreSQL and MySQL databases, the test library (normally) executes the following test procedure for every
|
|
test case:
|
|
|
|
- Log in to the rdbms as the user icinga_unittest with password icinga_unittest
|
|
- Use the icinga_unittest database (which must be existing)
|
|
- **Drop all tables** in the icinga_unittest database
|
|
- Create a new, clean database schema
|
|
|
|
If anything goes wrong during this procedure, the test will be skipped (because maybe you don't have a pgsql database, but
|
|
want to test mysql, for example).
|
|
|
|
### Setting up a test user and database in MySQL
|
|
|
|
In MySQL, it's best to create a user icinga_unittest@localhost, a database icinga_unittest and grant all privileges on
|
|
this database:
|
|
|
|
mysql -u root -p
|
|
mysql> CREATE USER `icinga_unittest`@`localhost` IDENTIFIED BY 'icinga_unittest';
|
|
mysql> CREATE DATABASE `icinga_unittest`;
|
|
mysql> GRANT ALL PRIVILEGES ON `icinga_unittest`.* TO `icinga_unittest`@`localhost`;
|
|
mysql> FLUSH PRIVILEGES;
|
|
mysql> quit
|
|
|
|
### Setting up a test user and database in PostgreSQL
|
|
|
|
In PostgreSQL, you have to modify the pg_hba database if you don't have password authentication set up (which often is
|
|
the case). In this setup the icinga_unittest user is set to trust authentication on localhost, which means that no
|
|
password is queried when connecting from the local machine:
|
|
|
|
sudo su postgres
|
|
psql
|
|
postgres=# CREATE USER icinga_unittest WITH PASSWORD 'icinga_unittest';
|
|
postgres=# CREATE DATABASE icinga_unittest;
|
|
postgres=# \q
|
|
bash$ createlang plpgsql icinga;
|
|
|
|
|
|
Add the following lines to your pg_hba.conf (etc/postgresql/X.x/main/pg_hba.conf under debian, /var/lib/pgsql/data/pg_hba.conf for Redhat/Fedora)
|
|
to enable trust authentication for the icingaweb user when connecting from the localhost.
|
|
|
|
local icinga_unittest icinga_unittest trust
|
|
host icinga_unittest icinga_unittest 127.0.0.1/32 trust
|
|
host icinga_unittest icinga_unittest ::1/128 trust
|
|
|