Comment on page
This is a simple framework for testing dns providers by making real requests.
There is a sequence of changes that are defined in the test file that are run against your chosen provider.
For each step, it will run the config once and expect changes. It will run it again and expect no changes. This should give us much higher confidence that providers will work in real life.
providers.jsonshould have an object for each provider type under test. This is identical to the json expected in
creds.jsonfor dnscontrol, except it also has a "domain" field specified for the domain to test. The domain does not even need to be registered for most providers. Note that
providers.jsonexpects environment variables to be specified with the relevant info.
Running a test
- 1.The integration tests need a test domain to run on. All the records of this domain will be deleted!
- 2.Define all environment variables expected for the provider you wish to run.
cd integrationTest && go test -v -provider $NAMEwhere $NAME is the name of the provider you wish to run.
egrep ROUTE53 providers.json
export ROUTE53_KEY="also redacted"
cd integrationTest # NOTE: Not needed if already in that subdirectory
go test -v -verbose -provider ROUTE53
-endflags allow you to run just a portion of the tests.
go test -v -verbose -provider ROUTE53 -start 16
go test -v -verbose -provider ROUTE53 -end 5
go test -v -verbose -provider ROUTE53 -start 16 -end 20
The actual tests are in the file
integrationTest/integration_test.go. The tests are in a little language which can be used to describe just about any interaction with the API. Look for the comment
START HEREor the line
func makeTestsfor instructions.
WARNING: THE RECORDS IN THE TEST DOMAIN WILL BE DELETED. Only use a domain that is not used in production. Some providers have a way to run tests on domains that aren't registered (often a test environment or a side-effect of the company not being a registrar). In other cases we use a domain we squat on, or we register a domain called
dnscontrol-$provider.comjust for testing.
ProTip: If you run these tests frequently (and we hope you do), you should create a script that you can
sourceto set these variables. Be careful not to check this script into Git since it contains credentials.