# ansible modules unit tests

**URL:** <https://forum.ansible.com/t/ansible-modules-unit-tests/14330>\
**Category:** Ansible Developer\
**Created:** [January 13, 2014, 1:49pm UTC](https://forum.ansible.com/t/ansible-modules-unit-tests/14330 "2014-01-13T13:49:07Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Willem\_de\_Groot](https://avatars.discourse-cdn.com/v4/letter/w/a183cd/32.png) [@Willem\_de\_Groot](https://forum.ansible.com/u/Willem_de_Groot)\
**Post date:** [January 13, 2014, 1:49pm UTC](https://forum.ansible.com/t/ansible-modules-unit-tests/14330/1 "2014-01-13T13:49:07Z")

</div>

Lots of code seems to be under test, but not all. I think function-level unit tests would benefit most of the more obscure code, such as authorized\_key.parseoptions() ( [https://github.com/ansible/ansible/blob/devel/library/system/authorized\_key#L174](https://github.com/ansible/ansible/blob/devel/library/system/authorized_key#L174) )  
I spent some time writing unit tests for this module, but I couldn’t find an elegant way to make it work with nosetests. The problem is a hardcoded toplevel main() call, that will make a regular import call sys.exit because of the missing boilerplate code.

Some random ideas to enable module unit tests:

1. Find a way to load an Ansible module without executing main(). For example, with imp.load\_module and stripping the main() call before evaluation. Quite ugly.
2. Refactor all modules to only call main() when **name** is ‘ **main** ’. Lots of work, possibly backwards incompatible.
3. Before importing, preprocess the module just like hacking/test-module does, to add the missing boilerplate code. Possibly slow.
4. …  
What do you think?

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\
**Post date:** [January 13, 2014, 2:32pm UTC](https://forum.ansible.com/t/ansible-modules-unit-tests/14330/2 "2014-01-13T14:32:48Z")

</div>

This is discussed quite a bit, and simply put, unit tests are totally inappropriate for something of this nature.

What we want are _integration_ tests, and are going to be working to roll something out here.

It absolutely shouldn’t be a unit test, because how in the world do you unit test ec2 with any reliability? The code ends up lying to itself.

I’m not interested in considering _units_ for something that needs better testing here, though currently underway is some work to clean up things like Runner’s code to allow unit testing at a cleaner level _there_.

The modules are going to be tested with playbooks and we hope to have something open-sourced soon in the coming months that provides some end-to-end testing of modules and playbook constructs, in real world scenarios using live systems, that is also user expandable via pull request.