% Test suite for ACL on git.liw.fi

Introduction
============

This is a test suite for my Gitano ACL setup on git.liw.fi. It is run
against either the real or a test instance of the setup. It requires
the person running it to have admin access on the Gitano instance,
so the tests can create and remove users and repositories.

Pre-requisites
==============

Yarn must be run with `--env` used to set the environment variables
`GITANO` and `GITHOST`. `GITANO` must be the Unix user for the
Gitano instance (typically `git`), and `GITHOST` must be the address
of the host (IP address or domain name).

The person running this test suite must be able to log in to the
Gitano instance using their normal ssh key. In other words,
`ssh "$GITANO@$GITHOST" whoami` must work.

See the `check` script for details on how to invoke yarn for this test
suite.

The test suite will create a user called `tstusr` and `tstusr2`, and
remove them after the test suite. The users may get created and
removed multiple times.

User creation
=============

The admin must be able to create and remove a user.

	SCENARIO admin can create and remove a user
	ASSUMING no tstusr user exists on server
	GIVEN an ssh key for tstusr
	WHEN admin creates user tstusr
	THEN user tstusr exists
	AND user tstusr can access gitano
	WHEN admin removes user tstusr
	THEN user tstusr doesn't exist
	FINALLY remove user tstusr on server

A non-admin mustn't be able to create or remove users.

	SCENARIO non-admin attempts to create or remove users
	ASSUMING no tstusr user exists on server
	AND no tstusr2 user exists on server
	GIVEN an ssh key for tstusr
	AND an ssh key for tstusr2
	WHEN admin creates user tstusr
	AND tstusr attempts to create user tstusr2
	THEN attempt failed with error matching "You may not perform site administration"
	FINALLY remove user tstusr on server


Implementation sections
=======================


Check results of attempted operation
------------------------------------

Some scenario steps attempt to do something which may (or should)
fail. This step verifies the result of such an attempt. It is
intentionally named to be quite generic so we don't need to have
multiple "foo failed with error..." steps.

	IMPLEMENTS THEN attempt failed with error matching "(.*)"
	grep "$MATCH_1" "$DATADIR/attempt.stderr"

ssh key generation
------------------

Our test users need ssh keys. We generate these on the fly rather than
storing them in git, so that if someone gets a copy of this test
suite, they don't have keys that can, at least temporarily, access the
gitano instance.

The key is stored as `$DATADIR/$USERNAME.key` (for the secret key;
public key adds `.pub` to the end of the pathname).

We run `ssh-keygen` with `-N` to set an empty passphrase. This is OK
for test keys that never leave the local system, because our shell
library makes sure `$DATADIR` is inaccessible to anyone else.

	IMPLEMENTS GIVEN an ssh key for (\S+)
	ssh-keygen -f "$DATADIR/$MATCH_1.key" -N ''

Check for users on server
-------------------------

We check for users on the server at various stages. Those tests are
collected here, since they're all quite similar. Since we do it in
several IMPLEMENTS sections, we have a shell function in the shell
library to contain the actual code.

First of all, we need to verify that there are no test related users
on the server. If there is, something's gone wrong in a previous run,
and things should be cleaned up manually. Or another run of the test
suite is going on, and we shouldn't interfere with that.

	IMPLEMENTS ASSUMING no (\S+) user exists on server
	if user_exists "$MATCH_1"
	then
		die "User $MATCH_1 exists on server, but shouldn't"
	fi

Verify a user exists on the server.

	IMPLEMENTS THEN user (\S+) exists
	user_exists "$MATCH_1"

Verify a user doesn't exist on the server.

	IMPLEMENTS THEN user (\S+) doesn't exist
	if user_exists "$MATCH_1"
	then
		die "User $MATCH_1 exists on server, but shouldn't"
	fi

Verify a user can actually access gitano (by invoking whoami). This is
necessary to make sure that user creation added the user's ssh key;
otherwise other test steps may fail for unrelated reasons and the test
suite may interpret that wrongly. Further, we make sure the user's ssh
key can access their account and not some other account.

	IMPLEMENTS THEN user (\S+) can access gitano
	run_gitano_as "$MATCH_1" whoami | grep "User name: $MATCH_1\$"

User creation
-------------

An admin creates a user on the server. Since we need to have a
separate step for when a non-admin attempts the same, we have a shell
function to do the actual work. The shell function also sets the ssh
key for the user.

	IMPLEMENTS WHEN admin creates user (\S+)
	user_add admin "$MATCH_1"

Attempt to create a user; check later if it worked.

	IMPLEMENTS WHEN (\S+) attempts to create user (\S+)
	attempt user_add "$MATCH_1" "$MATCH_2"

User removal
------------

Admin removes a user.

	IMPLEMENTS WHEN admin removes user (\S+)
	user_del admin "$MATCH_1"

Admin clean up user at end of scenario.

	IMPLEMENTS FINALLY remove user (\S+) on server
	user_del admin "$MATCH_1"