Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/bsnape/rspec-terraform
RSpec tests for your Terraform modules
https://github.com/bsnape/rspec-terraform
Last synced: 7 days ago
JSON representation
RSpec tests for your Terraform modules
- Host: GitHub
- URL: https://github.com/bsnape/rspec-terraform
- Owner: bsnape
- License: mit
- Created: 2015-08-20T12:39:46.000Z (about 9 years ago)
- Default Branch: master
- Last Pushed: 2015-09-10T17:41:11.000Z (about 9 years ago)
- Last Synced: 2024-08-02T00:26:31.793Z (3 months ago)
- Language: Ruby
- Size: 191 KB
- Stars: 92
- Watchers: 7
- Forks: 10
- Open Issues: 2
-
Metadata Files:
- Readme: README.md
- License: LICENSE.txt
Awesome Lists containing this project
- awesome-terraform - rspec-terraform - RSpec tests for your Terraform modules. (Testing / Miscellaneous)
- awesome-tf - rspec-terraform - RSpec tests for your Terraform modules. (Testing / Community providers)
README
# Rspec-Terraform
* [Motivation](#motivation)
* [Looking Ahead](#looking-ahead)
* [Usage](#usage)
* [Setup](#setup)
* [Matchers](#matchers)
* [Contributing](#contributing)
## Motivation
[Terraform](https://github.com/hashicorp/terraform) is an awesome way of provisioning your infrastructure. However, like
with any new tool, the ecosystem surrounding it is very immature. This can cause problems when sharing code or coming up
against the rough edges of a tool in active development.
The creation of `rspec-terraform` was initially intended to smooth the creation and sharing of common Terraform
modules. Some sort of basic testing would ensure a stable and clearly defined interface for each module.
### Looking Ahead
Eventually, a two-tiered approach to testing would be ideal.
Provisioning non-trivial infrastructure should involve the use of many Terraform modules (rather than defining
everything yourself). Taking AWS as an example, this might include VPCs, ASGs, SGs, public/private subnets etc. Each of
these modules should be unit tested using `rspec-terraform` so that the interfaces they expose are well-defined.
Assembling many individual modules into a cohesive platform should also - ideally - be tested. It's unclear at this
stage how this might look and is yet to be implemented. Something similar to
[`serverspec`](https://github.com/mizzy/serverspec) may work.
## Usage
As [outlined above](#motivation), only simple unit-test type operations are currently supported.
### Setup
You will need Ruby and bundler installed.
Create a `Gemfile` at the root of your Terraform module and add the following:
```ruby
source 'https://rubygems.org'
gem 'rspec-terraform'
```
Then install the gem:
```bash
bundle
```
### Matchers
**N.B.** You must set the provider for each test. This is best done in the opening `describe` block:
```ruby
describe 'tf-aws-vpc', provider: :aws do
...
end
```
At present, only the `AWS` provider is available.
The matchers currently implemented are:
1. `require_variables`
```ruby
it 'expects the correct variables to be provided' do
expected_variables = %w(vpccidr ec2nameserver region account envname domain)
expect('terraform plan').to require_variables expected_variables
end
```
2. `create_a_plan`
```ruby
it 'creates a plan' do
expect('terraform plan -var-file example_variables/test_values.tfvars').to create_a_plan
end
```
## Contributing
1. Fork it ( https://github.com/bsnape/rspec-terraform/fork )
2. Create your feature branch (`git checkout -b my-new-feature`)
3. Commit your changes (`git commit -am 'Add some feature'`)
4. Push to the branch (`git push origin my-new-feature`)
5. Create a new Pull Request