# Unit tests as part of configuration management **URL:** \ **Category:** Ansible Project\ **Created:** [February 11, 2013, 5:56am UTC](https://forum.ansible.com/t/unit-tests-as-part-of-configuration-management/12333 "2013-02-11T05:56:47Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![VK1](https://avatars.discourse-cdn.com/v4/letter/v/bbce88/32.png) [@VK1](https://forum.ansible.com/u/VK1)\ **Post date:** [February 11, 2013, 5:56am UTC](https://forum.ansible.com/t/unit-tests-as-part-of-configuration-management/12333/1 "2013-02-11T05:56:47Z")
Hi, I'm experimenting with ansible and wanted to know if there is an easy way to write test cases for each configurable task. One of the philosophies of an older config mgmt system I wrote many years ago was to encourage authors to create automated test(s) for each change made to a system. So, for example, if I have a module with a set of tasks to get sendmail working, we could run the module with a 'test' argument on client machines and have it report whether sendmail is configured correctly or not. I wouldn't care about each task within that module, just whether the entire goal of that module was accomplished. Scripts built on top of these could optionally skip those modules if the test cases succeeded. Audit reports across machines could summarize status in terms that were relatively easy to understand (compared to low level dry-run type of info). Naturally, the quality of test cases has a bearing on effectiveness, and I realize that there's some duplication of effort involved -- code to effect changes, and code to test. However, it is useful, and I'm curious how to accomplish the same with ansible? If it's not possible today, I'd like to request this as a feature. I'm having a bit of trouble with Google groups and their javascript-gone-wild, so I'll have to dig through the archives and read your thoughts on --check, which I happened to notice in passing a couple of days ago. Thanks. ---
**Author:** ![Brian\_Coca1](https://avatars.discourse-cdn.com/v4/letter/b/278dde/32.png) [@Brian\_Coca1](https://forum.ansible.com/u/Brian_Coca1)\ **Post date:** [February 12, 2013, 4:09pm UTC](https://forum.ansible.com/t/unit-tests-as-part-of-configuration-management/12333/2 "2013-02-12T16:09:59Z")
I use a couple of handlers as testers, nginx and nagios for example can be executed with a 'sanity check' of their config files. I'm looking into something for sudoers also. ---
**Author:** ![fdavis](https://avatars.discourse-cdn.com/v4/letter/f/a698b9/32.png) [@fdavis](https://forum.ansible.com/u/fdavis)\ **Post date:** [February 12, 2013, 11:20pm UTC](https://forum.ansible.com/t/unit-tests-as-part-of-configuration-management/12333/3 "2013-02-12T23:20:25Z")
I started a similar thread here, with a few ideas: [https://groups.google.com/forum/?fromgroups=#!topic/ansible-project/pLDZXCzchOQ](https://groups.google.com/forum/?fromgroups=#%21topic/ansible-project/pLDZXCzchOQ) Do you know how you would like to use such a feature? I am not sure where it would belong in a playbook. It sounds like it should be a per task parameter. If we can decide on a good example usage I can try to implement it, and see if anyone likes it. ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [February 12, 2013, 11:26pm UTC](https://forum.ansible.com/t/unit-tests-as-part-of-configuration-management/12333/4 "2013-02-12T23:26:49Z")
On the contrary, I think it is a playbook, and ansible doesn't need to do anything to support it. I support testing, but I want to limit syntax where cases are already well served. ---
**Author:** ![VK1](https://avatars.discourse-cdn.com/v4/letter/v/bbce88/32.png) [@VK1](https://forum.ansible.com/u/VK1)\ **Post date:** [February 13, 2013, 6:09am UTC](https://forum.ansible.com/t/unit-tests-as-part-of-configuration-management/12333/5 "2013-02-13T06:09:22Z")
Just took a look at that thread. I'm not entirely sure it's what I'm looking for, but I'm glad others are interested in something of this nature. I'd be happy with playbook level tests, and the task level tests would be a bonus. Being fairly new to ansible and not well versed in what it can do, I was merely stating the high level requirements. Within my organization, I'm looking at alternatives to the existing tool chain, which encourages: 1. Writing a unit test for every module that applies changes to a system (in this case I'd say a module translates to playbooks consisting of individual tasks) 2. Tight coupling of unit tests with the actual code that makes changes To illustrate this, here's a pseudo example of steps to setup sendmail: - stop sendmail if running - copy conf file for given profile - set correct perms on config file - run chkconfig to enable sendmail service - restart sendmail I'd like to be able to say something like: # ansible-playbook --brief --test sendmail.yml [host1] sendmail.yml: FAILED [host2] sendmail.yml: OK # ansible-playbook --brief --run --failedonly sendmail.yml [host1] sendmail.yml: OK and unless I wanted more verbose output, I wouldn't care about the individual tasks or task-level unit tests as much as that the macro changes succeeded or failed. Again, the above is simply to illustrate the point. I'll let more ansible-savvy folks translate ... ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [February 13, 2013, 1:20pm UTC](https://forum.ansible.com/t/unit-tests-as-part-of-configuration-management/12333/6 "2013-02-13T13:20:42Z")
I'm not open to integrated tests at this time because they can be solved with a test playbook. --Michael ---
**Author:** ![David\_Whiteside1](https://avatars.discourse-cdn.com/v4/letter/d/848f3c/32.png) [@David\_Whiteside1](https://forum.ansible.com/u/David_Whiteside1)\ **Post date:** [August 16, 2013, 2:13pm UTC](https://forum.ansible.com/t/unit-tests-as-part-of-configuration-management/12333/7 "2013-08-16T14:13:13Z")
Why not use tags for your unit tests? - David