Skip to content

Remove test boilerplate by adding build tag

Adam Snyderrequested to merge
github/fork/armsnyder/acceptance-tags into main

Description

Relates to #1008 (closed)

I'm interested in feedback on this. Is this a good change, if contributors now have to be sure to add the // +build acceptance header to new tests, or should we instead keep our test-skipping logic as it is?

The goal of this PR is to remove the testAccCheck(t) and PreCheck boilerplate code from all tests.

I was able to do this by introducing an "acceptance" build tag.

The 4 commits are independent, so you can review them separately.

  1. Run acceptance tests with acceptance build tag

    • I added the // +build acceptance build tag on all acceptance test files, but NOT unit test files. This allows us to run acceptance tests by specifying go test -tags acceptance, and keep the default go test command only running unit tests, without the need to check the value of TF_ACC in every test.

  2. Run tfproviderlint as a golangci-lint plugin

    • I changed the way that we run tfproviderlint so that instead of running the binary, we run it as a plugin of golangci-lint. This was necessary because tfproviderlint does not allow you to specify build tags, so it was not linting acceptance tests anymore. Whereas, golangci-lint does let you specify build tags.

  3. Allow linters to lint acceptance tests

    • Runs linters with --build-tags acceptance so that acceptance tests are included in linting.

  4. Remove skip-test checks and rely on build tags instead

    • Deleted all uses of testAccCheck and PreCheck. Now that acceptance tests are enabled using an acceptance build tag, we do not need to do these runtime checks.

PR Checklist Acknowledgement

  • I acknowledge that all of the following items are true, where applicable:
    • Resource attributes match 1:1 the names and structure of the API resource in the GitLab API documentation.
    • Examples are updated with:
      • A *.tf file for the resource/s with at least one usage example
      • A *.sh file for the resource/s with an import example (if applicable)
    • New resources have at minimum a basic test with three steps:
      • Create the resource
      • Update the attributes
      • Import the resource
    • No new //lintignore comments were copied from existing code. (Linter rules are meant to be enforced on new code.)

Merge request reports