Rename some suites and add a README for each of them.

This commit is contained in:
Clement Michaud 2019-03-02 23:05:57 +01:00
parent 6d45692906
commit 4c0bb2ce7f
31 changed files with 108 additions and 145 deletions

55
test/suites/README.md Normal file
View File

@ -0,0 +1,55 @@
# Authelia Suites
Authelia is a single component in interaction with many others. Consequently, testing the features
is not as easy as we might think. Consequently, a suite is kind of a virtual environment for Authelia,
it allows to create an environment made of components such as nginx, redis or mongo in which Authelia can
run and be tested.
This abstraction allows to prepare an environment for manual testing during development and also to
craft and run integration tests.
## Start a suite.
Starting a suite called *simple* is done with the following command:
npm run scripts suites start simple
It will start the suite and block until you hit ctrl-c to stop the suite.
## Run tests of a suite
### Run tests of running suite
If you are already running a suite with the previous command, you can simply type:
npm run scripts test
and this will run the tests related to the running suite.
### Run tests of non-running suite
However, if no suite is running and you still want to test a particular suite like *complete*.
You can do so with the next command:
npm run scripts test complete
This command will run the tests for the *complete* suite using the built version of Authelia that
should be located in *dist*.
WARNING: Authelia must be built before running this command.
### Run all tests of all suites
Running all tests is as easy as making sure that there is no running suite and typing:
npm run scripts test
## Create a suite
Creating a suite is as easy as creating a new directory with at least two files:
* **environment.ts** - It defines the setup and teardown phases when creating the environment. The *setup*
phase is the phase when the required components will be spawned and Authelia will start while the *teardown*
is executed when the suite is destroyed (ctrl-c hit by the user).
* **test.ts** - It defines a set of tests to run in the virtual environment of the suite.

View File

@ -0,0 +1,13 @@
# Basic suite
This suite has been created to test Authelia with basic feature in a non highly-available setup.
Authelia basically use an in-memory cache to store user sessions and persist data on disk instead
of using a remote database. Also, the user accounts are stored in file-based database.
## Components
Authelia, nginx, fake webmail for registering devices.
## Tests
Broad range of tests.

View File

@ -1,110 +0,0 @@
###############################################################
# Authelia minimal configuration #
###############################################################
port: 9091
logs_level: debug
default_redirection_url: https://home.example.com:8080/
authentication_backend:
file:
path: ./users_database.yml
session:
secret: unsecure_session_secret
domain: example.com
inactivity: 5000
expiration: 8000
# Configuration of the storage backend used to store data and secrets. i.e. totp data
storage:
local:
path: /tmp/authelia/db
# TOTP Issuer Name
#
# This will be the issuer name displayed in Google Authenticator
# See: https://github.com/google/google-authenticator/wiki/Key-Uri-Format for more info on issuer names
totp:
issuer: example.com
# Access Control
#
# Access control is a set of rules you can use to restrict user access to certain
# resources.
access_control:
# Default policy can either be `bypass`, `one_factor`, `two_factor` or `deny`.
default_policy: deny
rules:
- domain: single_factor.example.com
policy: one_factor
- domain: '*.example.com'
subject: "group:admins"
policy: two_factor
- domain: dev.example.com
resources:
- '^/users/john/.*$'
subject: "user:john"
policy: two_factor
- domain: dev.example.com
resources:
- '^/users/harry/.*$'
subject: "user:harry"
policy: two_factor
- domain: '*.mail.example.com'
subject: "user:bob"
policy: two_factor
- domain: dev.example.com
resources:
- '^/users/bob/.*$'
subject: "user:bob"
policy: two_factor
# Configuration of the authentication regulation mechanism.
regulation:
# Set it to 0 to disable max_retries.
max_retries: 3
# The user is banned if the authenticaction failed `max_retries` times in a `find_time` seconds window.
find_time: 10
# The length of time before a banned user can login again.
ban_time: 5
# Default redirection URL
#
# Note: this parameter is optional. If not provided, user won't
# be redirected upon successful authentication.
#default_redirection_url: https://authelia.example.domain
notifier:
# For testing purpose, notifications can be sent in a file
# filesystem:
# filename: /tmp/authelia/notification.txt
# Use your email account to send the notifications. You can use an app password.
# List of valid services can be found here: https://nodemailer.com/smtp/well-known/
## email:
## username: user@example.com
## password: yourpassword
## sender: admin@example.com
## service: gmail
# Use a SMTP server for sending notifications
smtp:
username: test
password: password
secure: false
host: 127.0.0.1
port: 1025
sender: admin@example.com

View File

@ -1,18 +0,0 @@
import { exec } from '../../helpers/utils/exec';
import ChildProcess from 'child_process';
async function setup() {
await exec('docker run -d -v $(pwd)/config.yml:/etc/authelia/config.yml --name authelia-test clems4ever/authelia > /dev/null');
console.log('Container has been spawned.');
}
async function teardown() {
try {
ChildProcess.execSync('docker ps | grep "authelia-test"');
await exec('docker rm -f authelia-test > /dev/null');
} catch (e) {
// If grep does not find anything, execSync throws an exception since the command returns 1.
}
}
export { setup, teardown };

View File

@ -1,17 +0,0 @@
import ChildProcess from 'child_process';
import Bluebird from 'bluebird';
import Assert from 'assert';
import sleep from '../../helpers/utils/sleep';
import AutheliaSuite from '../../helpers/context/AutheliaSuite';
const execAsync = Bluebird.promisify<string, string>(ChildProcess.exec);
AutheliaSuite('Test docker container runs as expected', __dirname, function() {
this.timeout(15000);
it('should be running', async function() {
await sleep(5000);
const output: string = await execAsync('docker ps -a | grep "authelia-test"');
Assert(output.match(new RegExp('Up [0-9]+ seconds')));
});
});

View File

@ -0,0 +1,13 @@
# Dockerhub suite
This suite is made to quickly test that the Docker image of Authelia runs properly when spawned.
It can also be used for you to test Authelia without building it since the latest image will be
pulled from Dockerhub.
## Components
This suite will spawn an highly-available setup with nginx, mongo, redis, OpenLDAP, etc...
## Tests
Check if the image runs and does not crash unexpectedly and do a simple authentication with 2FA.

View File

@ -0,0 +1,15 @@
# High-availability suite
This suite is made to test Authelia in a *complete* environment, that is, with
all components making Authelia highly available.
## Components
This suite will spawn nginx as the edge reverse proxy, redis and mongo for storing
user sessions and configurations, LDAP for storing user accounts and authenticating,
as well as a few helpers such as a fake webmail to receive e-mails sent by Authelia
and httpbin to check headers forwarded by Authelia.
## Tests
There is broad range of tests in this suite. Check out in the *scenarii* directory.

View File

@ -0,0 +1,12 @@
# Short timeouts suite
This suite has been created to configure Authelia with short timeouts for sessions expiration
in order to test the inactivity feature and the remember me feature.
## Components
Authelia, nginx and a fake webmail for registering a device.
## Tests
Related to user inactivity.