Five Questions: Testing Ansible Playbooks & Roles

Next up in our #AskAnsible posts is Chris Meyers, our Senior Software Engineer.

Learn his take on five key questions we often get regarding testing Ansible Playbooks and roles.

1. Why should I test my Playbooks and roles?

Chris: Ansible Playbooks and roles should be treated like production code. Production code usually has unit tests, functional tests, and integration tests.

• Unit testing Ansible is equivalent to unit testing SQL queries, you just normally don’t do it. Ansible unit testing belongs at the Python module level.
• Function testing with Ansible would require a large amount of system state setup or mocking, and it just isn't realistic. 
• Integration testing is the most useful. It ensures that your intent, expressed in English, is translated correctly to Ansible’s declarative language.
  • Ex: you want to set up a LAMP or MEAN stack. A simple integration test would be to issue an http request that you know exercises the database. The integration test would ensure that your setup is correct from end to end.

Chris: You can start at any time! Tests can be added for new Playbooks or to existing Playbooks. Testing Ansible Playbooks and roles are accomplished by simply running a Playbook or role. Thus, most of the testing work is just creating a clean host each time. This testing methodology coupled with Ansible’s flexible inventory system and per-host variables results in very little to no code changes (i.e. Playbook yaml and role task files).

3. How do I test my Playbooks and roles?

Chris: You are already testing your Playbooks and roles just by running them! But that is only one configuration matrix or permutation. You need to start by writing down the configuration matrix that you want to support. For example, if I want my role to support install PostgresSQL 9.4 and 9.6 and CentOS 7 and Ubuntu 14.04 then my configuration matrix would look like the following:

Now that we’ve pinned down the set of parameters our role supports we can clearly see that we need configurations to fully test our role.

We can represent each row in the configuration matrix as an inventory file. For example

[postgres]
ubuntu14

[postgres:vars]
pg_version=9.4

Or, since Ansible’s design makes it easy to run against multiple hosts, we can easily condense the test matrix down to two rows.

[postgres]
ubuntu14
centos7

[postgres:vars]
pg_version=9.6

The final piece for rapid development/testing is the ability to quickly reset the state of the hosts you are testing against.

For this I advise using docker. I’ve created a role called provision_docker that makes this process a little easier. Check out the Related Resources at the end of this post for more information.

4. What’s the benefit of testing my Playbooks and roles?

Chris: The benefits of testing Ansible Playbooks and roles are the same as the benefits of testing production code including:

• Faster turnaround of outside contributors
• Exercising less common code paths
• Increased confidence
• Early detection of Ansible version feature changes
• Up-to-date example use cases for users for free 

5. Will Ansible Playbook and role testing into my current CI flow?

Chris: Yes! The big component to testing Ansible roles and Playbooks is standing up a fresh remote “host." You can accomplish this using your existing methods or you can leverage Ansible public cloud modules such as EC2 or GCE or use Ansible private cloud modules such as VMware or openstack; to spin up remote instances. Alternatively, you can leverage the power of contains through provision_docker to turn a single bare metal or VM into a provider of multiple Ansible hosts.

Need more?

Learn how to Provision docker on Github

Watch Chris talk about the Build Passing Badge on Galaxy 

Read about testing Roles with docker 

Watch Chris talk about Ansible Roles and Projects

If you have any comments or ideas for future interviews, feel free to tweet at @Ansible.

 TWEET #ASKANSIBLE