Closed jeffmccune closed 5 years ago
My goal for this PR is to validate the spec test structure and get it reviewed and merged. Once approved, I'll add test coverage for existing functionality introduced in https://github.com/terraform-google-modules/terraform-google-startup-scripts/pull/1 and then continue to iterate on this by moving over the existing functions and their tests from the previous repository.
Is there a reason bats is preferred here over kitchen?
Is there a reason bats is preferred here over kitchen?
The main reason is they exist from the source copy and provide pretty good coverage, so they're speedy to move over.
The bats tests are modeled as unit spec tests distinct from integration tests. My thinking is we get all of the existing functionality and test coverage ported over so we have fast-running unit/spec level tests and behavior, then we scope out integration level tests as needed.
Rebased in 0f74e0d...74f2a7d HEAD -> test_structure (forced update)
Checks out:
docker rmi cftk/bats:0.4.0
make docker_build_bats
make docker_bats
Without this patch there is no test coverage for the startup scripts module. This patch sets up the initial test structure via two make targets, docker_bats to run the bats test suite inside of a container, and docker_build_bats to build the container image.