Skip to content
Branch: master
Find file History
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.

Testing the DCL

The code in this directory will test a remote DCL implementation.


This suite uses python to access (and test) remote DCL, through HTTPS and DNS protocols. It's developed with python 2.7, other versions may work but are not tested. The python code is tested in Linux and OSX. Raise an issue in if you encounter issues with other python versions or operating systems.

The script will install required python packagess. For it to succeed, the only dependencies you need to have is the pip and virtualenv.

The HTTPS implementation requires phantomjs, so you will also need that. Note, the Ubuntu OS packaged versons of phantomjs is known NOT to work, instead npm installed version. To do this in ubuntu, first install npm and nodejs-legacy, then use npm to install phantomjs-prebuilt:

$ apt-get install -y nodejs-legacy npm
$ npm install -g phantomjs-prebuilt


The software will evaluate the target, unless you don't override this behavior by setting appropriate environment varialbes.

There is a configuration file mechanism for setting the environment variables in a convenient way. If test/ exists, any variables it exports will be set in the test runner's environment.

To customise the test target:

  1. cp
  2. edit to reffer to your chosen target
  3. run the script as usual. contains all the variables that the test suite currently uses, with some documentation of their purpose. The values of these variables in this file are equivalent to the default values (including this file as-is has no actual effect).

note: is excluded from the repository (.gitignore). Your local configuration will not be overwritten by updates.

Warning: Concurrent use of DCL_TEST_USER

If multiple people are running the test suite in parallel with the same DCL_TEST_USER, it's possible the tests will collide (causing false results). If that's an issue for you, it's advisable to reserve your own test accounts and use them exclusively.

If you are running against, you can claim ABNs for exclusive use on Log in with a developer account (GitHub user) to manage your own collection of ABNs, create new ABN and try to login manually from with newly created credential to ensure it works.

Running the test suite

Assuming you have python, pip and virtualenv, the script will run the test suite against the configured (or default) target, and print the results to the STDOUT.

If there is no virtualenv installed in the current directory (in a directory named .venv), will create one there and then install the required packages into it. Delete this directory between test runs to be certain all the dependencies are up to date. Alternatively, leave the virtualenv in place to minimise time and bandwidth of each test run.

Typically, a developer making frequent changes would keep the virtualenv in place, but integration tests would use a fresh install every time.

Test runner options inherits many features from the py.test package, run --help to see the options.

Some output formatting options worth noting:

  • -v provides more verbose output
  • --spec produces verbose output in a diffent format
  • --quite supresses output unless a defect is found
  • --junit-xml=path produces test result in junit format, which may be useful for issue tracking through a CI server.

Sample Code

/ contains code that may be useful if you are looking for a simple demonstration of ways to interact with a DNS NAPTR records.

For examples see client_side/ or / Note, the ./ wrapper calls the python script with the appropraite virtualenv (same trick as, which may be a convenieint way to run it.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.