ansible modules unit tests

183 views
Skip to first unread message

Willem de Groot

unread,
Jan 13, 2014, 8:49:07 AM1/13/14
to ansibl...@googlegroups.com
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 )
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?
 





Michael DeHaan

unread,
Jan 13, 2014, 9:32:48 AM1/13/14
to Willem de Groot, ansibl...@googlegroups.com
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.




--
You received this message because you are subscribed to the Google Groups "Ansible Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-deve...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.



--
Michael DeHaan <mic...@ansibleworks.com>
CTO, AnsibleWorks, Inc.
http://www.ansibleworks.com/

Reply all
Reply to author
Forward
0 new messages