@ -27,7 +27,7 @@ Let's say we want to test the ``postgresql_user`` module invoked with the ``name
..code-block:: yaml
..code-block:: yaml
- name: Create PostgreSQL user and store module's output to the result variable
- name: Create PostgreSQL user and store module's output to the result variable
postgresql_user:
community.postgresql.postgresql_user:
name: test_user
name: test_user
register: result
register: result
@ -37,7 +37,7 @@ Let's say we want to test the ``postgresql_user`` module invoked with the ``name
- result is changed
- result is changed
- name: Check actual system state with another module, in other words, that the user exists
- name: Check actual system state with another module, in other words, that the user exists
postgresql_query:
community.postgresql.postgresql_query:
query: SELECT * FROM pg_authid WHERE rolename = 'test_user'
query: SELECT * FROM pg_authid WHERE rolename = 'test_user'
register: query_result
register: query_result
@ -129,7 +129,7 @@ To check a task:
2. If the module changes the system state, check the actual system state using at least one other module. For example, if the module changes a file, we can check that the file has been changed by checking its checksum with the :ref:`stat <ansible_collections.ansible.builtin.stat_module>` module before and after the test tasks.
2. If the module changes the system state, check the actual system state using at least one other module. For example, if the module changes a file, we can check that the file has been changed by checking its checksum with the :ref:`stat <ansible_collections.ansible.builtin.stat_module>` module before and after the test tasks.
3. Run the same task with ``check_mode: yes`` if check-mode is supported by the module. Check with other modules that the actual system state has not been changed.
3. Run the same task with ``check_mode: yes`` if check-mode is supported by the module. Check with other modules that the actual system state has not been changed.
4. Cover cases when the module must fail. Use the ``ignore_errors: yes`` option and check the returned message with the ``assert`` module.
4. Cover cases when the module must fail. Use the ``ignore_errors: true`` option and check the returned message with the ``assert`` module.
Example:
Example:
@ -139,7 +139,6 @@ Example:
abstract_module:
abstract_module:
...
...
register: result
register: result
ignore_errors: yes
- name: Check the task fails and its error message
- name: Check the task fails and its error message
# We should also run the same tasks with check_mode: yes. We omit it here for simplicity.
# We should also run the same tasks with check_mode: yes. We omit it here for simplicity.
- name: Test for new_option, create new user WITHOUT the attribute
- name: Test for new_option, create new user WITHOUT the attribute
postgresql_user:
community.postgresql.postgresql_user:
name: test_user
name: test_user
add_attribute: no
register: result
register: result
- name: Check the module returns what we expect
- name: Check the module returns what we expect
@ -119,7 +118,7 @@ We will add the following code to the file.
- result is changed
- result is changed
- name: Query the database if the user exists but does not have the attribute (it is NULL)
- name: Query the database if the user exists but does not have the attribute (it is NULL)
postgresql_query:
community.postgresql.postgresql_query:
query: SELECT * FROM pg_authid WHERE rolename = 'test_user' AND attribute = NULL
query: SELECT * FROM pg_authid WHERE rolename = 'test_user' AND attribute = NULL
register: result
register: result
@ -129,9 +128,8 @@ We will add the following code to the file.
- result.query_result.rowcount == 1
- result.query_result.rowcount == 1
- name: Test for new_option, create new user WITH the attribute
- name: Test for new_option, create new user WITH the attribute
postgresql_user:
community.postgresql.postgresql_user:
name: test_user
name: test_user
add_attribute: yes
register: result
register: result
- name: Check the module returns what we expect
- name: Check the module returns what we expect
@ -140,7 +138,7 @@ We will add the following code to the file.
- result is changed
- result is changed
- name: Query the database if the user has the attribute (it is TRUE)
- name: Query the database if the user has the attribute (it is TRUE)
postgresql_query:
community.postgresql.postgresql_query:
query: SELECT * FROM pg_authid WHERE rolename = 'test_user' AND attribute = 't'
query: SELECT * FROM pg_authid WHERE rolename = 'test_user' AND attribute = 't'
register: result
register: result
@ -153,16 +151,16 @@ Then we :ref:`run the tests<collection_run_integration_tests>` with ``postgresql
In reality, we would alternate the tasks above with the same tasks run with the ``check_mode: yes`` option to be sure our option works as expected in check-mode as well. See :ref:`Recommendations on coverage<collection_integration_recommendations>` for details.
In reality, we would alternate the tasks above with the same tasks run with the ``check_mode: yes`` option to be sure our option works as expected in check-mode as well. See :ref:`Recommendations on coverage<collection_integration_recommendations>` for details.
If we expect a task to fail, we use the ``ignore_errors: yes`` option and check that the task actually failed and returned the message we expect:
If we expect a task to fail, we use the ``ignore_errors: true`` option and check that the task actually failed and returned the message we expect:
..code-block:: yaml
..code-block:: yaml
- name: Test for fail_when_true option
- name: Test for fail_when_true option
postgresql_user:
community.postgresql.postgresql_user:
name: test_user
name: test_user
fail_when_true: yes
fail_when_true: true
register: result
register: result
ignore_errors: yes
ignore_errors: true
- name: Check the module fails and returns message we expect
- name: Check the module fails and returns message we expect