This document discusses testing infrastructure as code (IaaC) using test-driven development (TDD) principles. It recommends applying different types of automated tests for IaaC: unit tests to check for errors, integration tests to validate functionality, and acceptance/security tests on deployed infrastructure. Various tools are mentioned for testing IaaC written in languages like Terraform, Ansible, Chef, and Puppet at the unit, integration, and security levels. Adopting a testing mindset and tools can help catch errors and non-compliance early in development pipelines.

1. TDD for IaaC
the future trend
Dnipro, 28th feb 2018 Gianfranco Panico

2. привіт
I am Gianfranco
Dreaming of a world with more and better
automation:
- spreading DevOps mentality
- educating to correct InfraDev approach

3. Why Testing IaaC
… and why we aren’t already doing it!
1

4. “
“Confidence in code
without tests
is false confidence”.
Buddha

5. Typical IaaC
caveats
The 200 paradigm
Stack deployments in the Cloud
are mostly requests to undergo
some provisioning actions. HTTP
status 200 means ‘copy’ not
‘done’.
Cloud provider changes
AWS keeps “improving” their
offer – adding instance types,
increasing the length of some IDs,
changing SSL certs for services –
every second day.
Collaboration
I ansible this box here, you
terraform that DB instance there,
works fine, right?
Delays & Dependancies
That forgotten firewall rule that
won’t let you download the
Docker image from your registry.
Timeouts
Lambdas timeout happily. Cross
region transfers – guess what? –
do timeout too!
Some operations with infras are
inherently long, and don’t give
much sign of progression.
Works… too much
The resource is deployed, the
service is up, the port is open.
And all other 65534 ports are –
as well!

6. Infra as a Code
means
applying SDLC methods and
tooling to Infrastructure
Development

7. TDD teachings
Let’s learn from our beloved Devs
2

8. TDD loop
1. THINK of an expected behaviour
2. WRITE a test that fails
3. WRITE code to pass the test
4. REFACTOR
5. GOTO 1.

9. 1. THINK of an expected behaviour
2. WRITE a test that fails
3. WRITE code to pass the test
4. REFACTOR
5. GOTO 1.
var strong = isStrongPassword('password string');
describe('isPasswordStrong', function() {
it('should give negative result for empty string', function() {
var password = '';
var result = isPasswordStrong(password);
expect(result).to.be.false;
});
});
function isPasswordStrong(password) {
if(!password) {
return false;
}
}

10. unit
integration
Oh Not Yet Another Test Pyramid
acceptance
Do our CD scripts work?
Are instances up?
Am I missing some best
coding practice?
Is code style “decent” enough?
Can they connect
to the DB/ELB…?
Is Bastion Host up and connectable?
How’s the security of VPCs?
Am I actually solving the right problem?
slow
expensive

11. Test types for Infra
Unit
◇ No code is actually
run
◇ Check internal
consistency
◇ Check format/style
◇ Check intrinsic
language constructs
Integration
◇ Code is run
◇ Systems are
provisioned
◇ The result is
validated
◇ E2E / functional
testing goes here
Security
◇ On already deployed
infra
◇ Scans for “excesses”
◇ Respondance to
hardening
standards
◇ Infra-compliance

12. The tools?
Are here.

13. *specLinter
Unit testing
IaaC
Formatter
Ruby
terraform
puppet
rubocop
YAML
ansible_spec
foodcritic
align-yaml
HCL
tf fmt
chef
ansible
chefspec
tflint
terraform-spec
tf plan
ansible-lint
tf validate

14. rubocop & foodcritic

15. validate, fmt & tflint

16. chefspec

17. Functional
Integration
testing IaaC
Ruby
terraform
puppet
YAML HCL
chef
ansible
ServerSpec
tf plan
ansible --check
AWSpec

18. kitchenCI
ansible Terraform
kitchen-terraform provisioner
(on Vagrant)
YAML HCL
Ruby
puppetchef
$ kitchen converge
ServerSpec
InSpec

19. Acceptance
Security
testing IaaC
Ruby
puppet
nmap
chef
InSpec
gauntlt
Se
BDD-security
Owasp zed
attack proxy

20. Computing the sha384sum digest of the deployable
package
$ sha512sum app123.war > app123.sig
and then having Jenkins verify the checksum at deploy
stage
$ sha512sum –c app123.sig app123.war 2>&1 |
grep OK
app_v123.war: OK
Trustable artifact
to guarantee that each and every deployable component had been built through
automation, and as such, has been tested fully before being promoted to production.

21. Compliance
Compliance
IaaC
AWS
Config
AWS
Lambda
CloudTrail
CloudWatch
signed-artifact
deployment

22. What to do next
spread the voice
develop &
share tools
build best
practices

23. Thanks!
Any questions?
Credits: PPT template by SlidesCarnival