1
0
mirror of https://github.com/StackExchange/dnscontrol.git synced 2024-05-11 05:55:12 +00:00

Tests: ensure provider capabilities are checked (#650)

* Tests: ensure provider capabilities are checked

Adds test: `TestCapabilitiesAreFiltered`

We have a number of records and pseudo-records which in theory can only
be used with a given provider if that provider indicates support.  In
practice, we've been missing the checks for that support and have been
passing the records down anyway.  The advice comment in the
providers/capabilities.go file to edit `checkProviderCapabilities()` has
not been reliably followed.

We need an internal self-consistency test.  The constants are not
directly exported or enumerable based solely on the package interfaces
at run-time, but with source access for a test suite, we can use the
`go/ast` and related interfaces to examine the code, extract all the
constants from a given package, figure out which ones we want to be
handled, and then insist that they're handled.

Before my recent work, we only checked:

    ALIAS PTR SRV CAA TLSA

After this commit, we check:

    ALIAS AUTODNSSEC CAA NAPTR PTR R53_ALIAS SSHFP SRV TLSA

I've added `AUTODNSSEC` as a new feature; `SSHFP` and `PTR` were caught
in other recent commits from me; implementing this test caused me to
have to add `NAPTR` and `R53_ALIAS`.  I whitelist `CanUseTXTMulti` as a
special-case.

This should prevent regressions.  We will probably want to post publicly
to warn people that if they're using SSHFP/PTR/NAPTR/R53_ALIAS then they
should check the feature matrix and if they don't see their provider
listed, to report is as "hey that actually works" so we can update the
provider flags.  Bonus: our feature matrix will suddenly be more
accurate.

* Add comments/docs for capabilities authors

* fixup!

* fixup!
This commit is contained in:
Phil Pennock
2020-02-25 07:22:32 -05:00
committed by GitHub
parent 3ce5b22d1a
commit 4fed6534c7
3 changed files with 123 additions and 8 deletions

View File

@@ -48,7 +48,8 @@ type RecordConfig struct {
You'll need to mark which providers support this record type. The
initial PR should implement this record for the `bind` provider at
a minimum.
a minimum, unless this is a fake or pseudo-type that only a particular
provider supports.
* Add the capability to the file `dnscontrol/providers/capabilities.go` (look for `CanUseAlias` and add
it to the end of the list.)
@@ -60,10 +61,32 @@ it to the end of the list.)
`pkg/normalize/validate.go`.
* Mark the `bind` provider as supporting this record type by updating `dnscontrol/providers/bind/bindProvider.go` (look for `providers.CanUse` and you'll see what to do).
DNSControl will warn/error if this new record is used with a
provider that does not support the capability.
* Add the capability to the validations in `pkg/normalize/validate.go`
by adding it to `providerCapabilityChecks`
* Some capabilities can't be tested for, such as `CanUseTXTMulti`. If
such testing can't be done, add it to the whitelist in function
`TestCapabilitiesAreFiltered` in
`pkg/normalize/capabilities_test.go`
If the capabilities testing is not configured correctly, `go test ./...`
will report something like the `MISSING` message below. In this
example we removed `providers.CanUseCAA` from the
`providerCapabilityChecks` list.
```
--- FAIL: TestCapabilitiesAreFiltered (0.00s)
capabilities_test.go:66: ok: providers.CanUseAlias (0) is checked for with "ALIAS"
capabilities_test.go:68: MISSING: providers.CanUseCAA (1) is not checked by checkProviderCapabilities
capabilities_test.go:66: ok: providers.CanUseNAPTR (3) is checked for with "NAPTR"
```
## Step 3: Add a helper function
Add a function to `pkg/js/helpers.js` for the new record type. This
is the Javascript file that defines `dnsconfig.js`'s functions like
is the JavaScript file that defines `dnsconfig.js`'s functions like
`A()` and `MX()`. Look at the definition of A, MX and CAA for good
examples to use as a base.
@@ -99,6 +122,10 @@ As you debug, if there are places that haven't been marked
`#rtype_variations` that should be, add such a comment.
Every time you do this, an angel gets its wings.
The tests also verify that for every "capability" there is a
validation. This is explained in Step 2 (search for
`TestCapabilitiesAreFiltered` or `MISSING`)
## Step 6: Add an `integrationTest` test case.
Add at least one test case to the `integrationTest/integration_test.go`