Testing acme-tiny requires a bit of setup since it interacts with other servers (Let's Encrypt's staging server) to test issuing fake certificates. This readme explains how to setup and test acme-tiny yourself.
export TRAVIS_DOMAIN=travis-ci.gethttpsforfree.com
$TRAVIS_DOMAIN
for redirection of
http://$TRAVIS_DOMAIN/.well-known/acme-challenge/
to
http://localhost:8888/
openssl rand -base64 32
export TRAVIS_SESSION="<random_string_here>"
scp server.py ubuntu@travis-ci.gethttpsforfree.com
ssh ubuntu@travis-ci.gethttpsforfree.com
export TRAVIS_SESSION="<random_string_here>"
sudo server.py
sudo apt-get install fuse
virtualenv /tmp/venv
source /tmp/venv/bin/activate
pip install -r requirements.txt
cd /path/to/acme-tiny
coverage run --source ./ --omit ./tests/server.py,./setup.py -m unittest tests
Acme-tiny writes the challenge files for certificate issuance. In order to do full integration tests, we actually need to serve correct challenge files to the Let's Encrypt staging server on a real domain that they can verify. However, Travis-CI doesn't have domains associated with their test VMs, so we need to send the files to the remote server that does have a real domain.
The test suite uses FUSE to do this. It creates a FUSE folder that simulates being a real folder to acme-tiny. When acme-tiny writes the challenge files in the mock folder, FUSE POSTs those files to the real server (which is running the included server.py), and the server starts serving them. That way, both acme-tiny and Let's Encrypt staging can verify and issue the test certificate. This technique allows for high test coverage on automated test runners (e.g. Travis-CI).