ansible/test
John R Barker 04e816e13b Stricter module documentation validation (#22353)
Raise the bar for module `DOCUMENTAION`
This validator update was used to find the issues in https://github.com/ansible/ansible/pull/22297/files

**Validation**
* Updated Validation and docs to enforce more (items fixed in https://github.com/ansible/ansible/pull/22297/files)
* Use `suboptions` to document complex options 
* Validate module name
* Validate deprecated modules have correct ANSIBLE_METADATA

**Module Documentation Generation**
* Document `suboptions:` Example https://gist.github.com/gundalow/4bdc3669d696268328ccc18528cc6718
* Tidy up HTML generation (valid HTML, no empty lists, etc)
 
**Documentation**
* Clarify the steps for deprecating a module
* Use correct RST headings
* Document `suboptions:` (options)
* Document `contains:` (returns)


**Details**
The aim is to get this (and corresponding module updates) complete by the time `devel` becomes `2.4`, as this allows us to raise the bar for new modules

Example `suboptions` https://gist.github.com/gundalow/4bdc3669d696268328ccc18528cc6718

The aim is to get this PR integrated into `devel` *before* we branch `stable-2.3`, this will allows us to:
* Raise the bar for new modules in 2.4
* Ensure the generated module documentation for 2.3 and higher is improved, important as we will be doing versioned docs moving forward.
2017-03-13 19:49:27 +00:00
..
compile
integration fixes candidate var type in junos shared lib (#22551) 2017-03-13 07:27:45 -04:00
results
runner
sanity Stricter module documentation validation (#22353) 2017-03-13 19:49:27 +00:00
units
utils
README.md

Ansible Test System

Folders

units

Unit tests that test small pieces of code not suited for the integration test layer, usually very API based, and should leverage mock interfaces rather than producing side effects.

Playbook engine code is better suited for integration tests.

Requirements: sudo pip install paramiko PyYAML jinja2 httplib2 passlib nose pytest mock

integration

Integration test layer, constructed using playbooks.

Some tests may require cloud credentials, others will not, and destructive tests are separated from non-destructive so a subset can be run on development machines.

learn more

hop into a subdirectory and see the associated README.md for more info.