Tests for Ansible Collections are a vital ingredient of transitioning from "this module works for me" to a product that our users can use to deploy production environments. Why? There are lots of reasons for this, but the ones we think are the most important are:
Just thinking about how we would go about testing a particular piece of code will help us structure it better. Complex code is hard to test.
Writing integration tests allows us to verify our API design. If we are having trouble using our content in test playbooks, our users will have problems, too (and will rightfully hate us for this).
Running sanity tests regularly can help us prevent our implementation and documentation from diverging.
Having a comprehensive battery of tests makes it easy to extend our Ansible Collection without breaking existing playbooks. For example, pinning down the public API using unit tests is an excellent way to ensure we do not break backward compatibility inadvertently.
Since Ansible Collections are a link between Ansible and automated product, we need to run our integration tests on all supported Ansible and product version combinations. Our users will greatly appreciate it.
And remember, happy users mean happy bosses. Win-win ;)
Top comments (0)