internet/community.general
3
0
Fork 0
mirror of https://github.com/ansible-collections/community.general.git synced 2026-05-06 05:12:45 +00:00
Code Issues Packages Projects Releases Wiki Activity

Mdd module unit test docs (#31373)

Browse Source 
* new documentation for unit testing - especially module unit testing

* unit test documentation reformatting and further fixes

* unit test documentation - point to online coverage reports & fix bad spaces

* Small copy edits.

* First pass copy edit / rewrite. More info needed.

* testing documentation - clean up structure, especially code coverage - reduce repetition

* module unit test documentation - improved introduction

* testing documentation - more fixes from and inspired by review from dharmabumstead

* testing documentation - fixes from mattclay + some other minor tweaks

* More copy edits.

* testing documentation - further fixes from review

* Copy edits

* Copy edits

* More copy edits.
This commit is contained in:
mikedlr
2017-10-19 21:36:57 +01:00
committed by Toshio Kuratomi
parent c02173880a
commit fbbffbabde
4 changed files with 716 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
docs/docsite/rst/dev_guide/testing.rst
View File

@@ -33,9 +33,14 @@ At a high level we have the following classifications of tests:
* Tests directly against individual parts of the code base.
If you're a developer, one of the most valuable things you can do is look at the GitHub issues list and help fix bugs. We almost always prioritize bug fixing over feature development, so helping to fix bugs is one of the best things you can do.
If you're a developer, one of the most valuable things you can do is look at the GitHub
issues list and help fix bugs. We almost always prioritize bug fixing over feature
development.
Even if you're not a developer, helping to test pull requests for bug fixes and features is still immensely valuable.
Even for non developers, helping to test pull requests for bug fixes and features is still
immensely valuable. Ansible users who understand writing playbooks and roles should be
able to add integration tests and so Github pull requests with integration tests that show
bugs in action will also be a great way to help.
Testing within GitHub & Shippable
@@ -47,7 +52,6 @@ Organization
When Pull Requests (PRs) are created they are tested using Shippable, a Continuous Integration (CI) tool. Results are shown at the end of every PR.
When Shippable detects an error and it can be linked back to a file that has been modified in the PR then the relevant lines will be added as a GitHub comment. For example::
The test `ansible-test sanity --test pep8` failed with the following errors:
@@ -69,7 +73,6 @@ Then run the tests detailed in the GitHub comment::
ansible-test sanity --test pep8
ansible-test sanity --test validate-modules
If there isn't a GitHub comment stating what's failed you can inspect the results by clicking on the "Details" button under the "checks have failed" message at the end of the PR.
Rerunning a failing CI job
@@ -91,10 +94,6 @@ If the issue persists, please contact us in ``#ansible-devel`` on Freenode IRC.
How to test a PR
================
If you're a developer, one of the most valuable things you can do is look at the GitHub issues list and help fix bugs. We almost always prioritize bug fixing over feature development, so helping to fix bugs is one of the best things you can do.
Even if you're not a developer, helping to test pull requests for bug fixes and features is still immensely valuable.
Ideally, code should add tests that prove that the code works. That's not always possible and tests are not always comprehensive, especially when a user doesn't have access to a wide variety of platforms, or is using an API or web service. In these cases, live testing against real equipment can be more valuable than automation that runs against simulated interfaces. In any case, things should always be tested manually the first time as well.
Thankfully, helping to test Ansible is pretty straightforward, assuming you are familiar with how Ansible works.
@@ -188,8 +187,26 @@ If the PR does not resolve the issue, or if you see any failures from the unit/i
| some other output
| \```
Code Coverage Online
````````````````````
`The online code coverage reports <https://codecov.io/gh/ansible/ansible>` are a good way
to identify areas for testing improvement in Ansible. By following red colors you can
drill down through the reports to find files which have no tests at all. Adding both
integration and unit tests which show clearly how code should work, verify important
Ansible functions and increase testing coverage in areas where there is none is a valuable
way to help improve Ansible.
The code coverage reports only cover the ``devel`` branch of Ansible where new feature
development takes place. Pull requests and new code will be missing from the codecov.io
coverage reports so local reporting is needed. Most ``ansible-test`` commands allow you
to collect code coverage, this is particularly useful to indicate where to extend
testing. See :doc:`testing_running_locally` for more information.
Want to know more about testing?
================================
If you'd like to know more about the plans for improving testing Ansible then why not join the `Testing Working Group <https://github.com/ansible/community/blob/master/meetings/README.md>`_.
If you'd like to know more about the plans for improving testing Ansible then why not join the
`Testing Working Group <https://github.com/ansible/community/blob/master/meetings/README.md>`_.