ansible/docs/docsite/rst/dev_guide/testing/sanity/no-assert.rst

no-assert
=========

Do not use ``assert`` in production Ansible python code. When running Python
with optimizations, Python will remove ``assert`` statements, potentially
allowing for unexpected behavior throughout the Ansible code base.

Instead of using ``assert`` you should utilize simple ``if`` statements,
that result in raising an exception. There is a new exception called
``AnsibleAssertionError`` that inherits from ``AnsibleError`` and
``AssertionError``. When possible, utilize a more specific exception
than ``AnsibleAssertionError``.

Modules will not have access to ``AnsibleAssertionError`` and should instead
raise ``AssertionError``, a more specific exception, or just use
``module.fail_json`` at the failure point.
Remove redundant "Sanity Tests »" from page title. The docs now have multi-level breadcrumbs so including "Sanity Tests »" in the title on a sanity test page is redundant. 2019-07-26 17:51:09 +02:00			`no-assert`
			`=========`
Remove uses of assert in production code (#32079) * Remove uses of assert in production code * Fix assertion * Add code smell test for assertions, currently limited to lib/ansible * Fix assertion * Add docs for no-assert * Remove new assert from enos * Fix assert in module_utils.connection 2017-11-13 17:51:18 +01:00
			Do not use ``assert`` in production Ansible python code. When running Python
			with optimizations, Python will remove ``assert`` statements, potentially
			`allowing for unexpected behavior throughout the Ansible code base.`

			Instead of using ``assert`` you should utilize simple ``if`` statements,
			`that result in raising an exception. There is a new exception called`
			``AnsibleAssertionError`` that inherits from ``AnsibleError`` and
			``AssertionError``. When possible, utilize a more specific exception
			than ``AnsibleAssertionError``.

			Modules will not have access to ``AnsibleAssertionError`` and should instead
			raise ``AssertionError``, a more specific exception, or just use
			``module.fail_json`` at the failure point.