validations_common.tests.callback_plugins.test_validation_output module¶
test_validation_output¶
Tests for validation_output callback plugin.
- class validations_common.tests.callback_plugins.test_validation_output.DummyResults[source]¶
Bases:
dict
DummyResults is used in tests as a substitute, mimicking the behavior of the ansible.executor.task_results.TaskResults class.
- class validations_common.tests.callback_plugins.test_validation_output.MockStats(*args, **kw)[source]¶
Bases:
unittest.mock.MagicMock
MockStats mimics some behavior of the ansible.executor.stats.AggregateStats. Othewise it behaves like an ordinary MagicMock
- summary = {}¶
- class validations_common.tests.callback_plugins.test_validation_output.TestValidationOutput(*args: Any, **kwargs: Any)[source]¶
Bases:
validations_common.tests.base.TestCase
- test_callback_instantiation()[source]¶
Verifying that the CallbackModule is instantiated properly. Test checks presence of CallbackBase in the inheritance chain, in order to ensure that folowing tests are performed with the correct assumptions.
- test_print_failure_message_rc_and_cmd(mock_display, mock_failure_template, mock_pprint, mock_color_warn, mock_color_error)[source]¶
The test places assertions on the values of arguments passed to the format method of the FAILURE_TEMPLATE obj, and the display method of the ansible.utils.display.Display class. As such it mostly deals with string manipulation, and is therefore sensitive to localisation and formatting changes, including the color of the output text. The test assumes that both ‘rc’ and ‘cmd’ keys are present within the results object.
- test_print_failure_message_script(mock_display, mock_failure_template, mock_pprint, mock_color_warn, mock_color_error)[source]¶
The test places assertions on the values of arguments passed to the format method of the FAILURE_TEMPLATE obj, and the display method of the ansible.utils.display.Display class. As such it mostly deals with string manipulation, and is therefore sensitive to localisation and formatting changes, including the color of the output text.
- test_print_failure_message_unknown_error_no_warn(mock_display, mock_failure_template, mock_pprint, mock_color_warn, mock_color_error)[source]¶
The test places assertions on the values of arguments passed to the format method of the FAILURE_TEMPLATE obj, the display method of the ansible.utils.display.Display class and the pprint method. As such it mostly deals with string manipulation, and is therefore sensitive to localisation and formatting changes, including the color of the output text. Test assumes that neither pair of ‘rc’ and ‘cmd’ keys, nor the ‘msg’ key, exists within the results object. Therefore an Unknown error is assumed to have occured and output is adjusted accordignly. Furthermore, the test assumes that in absence of ‘warnings’ key, no warnings will be passed to the display method.
- test_print_failure_message_unknown_error_warn(mock_display, mock_failure_template, mock_pprint, mock_color_warn, mock_color_error)[source]¶
The test places assertions on the values of arguments passed to the format method of the FAILURE_TEMPLATE obj, the display method of the ansible.utils.display.Display class and the pprint method. As such it mostly deals with string manipulation, and is therefore sensitive to localisation and formatting changes, including the color of the output text. Test assumes that neither pair of ‘rc’ and ‘cmd’ keys, nor the ‘msg’ key, exists within the results object. Therefore an Unknown error is assumed to have occured and output is adjusted accordignly. Furthermore, the test assumes that when the ‘warnings’ key is present, the display method will be called with list entries as arguments.
- test_v2_playbook_on_stats_all_fail(mock_callback_base, mock_display, mock_sorted, mock_print, mock_color_ok, mock_color_error)[source]¶
When at all hosts are specified as failure and/or unreachable we expect them to be considered a failure and the display method to be called with the appropriate arguments in the proper order. The final call to print function is not an ideal place for assertion, as the string might get localised and/or adjusted in the future.
- test_v2_playbook_on_stats_no_fail(mock_callback_base, mock_display, mock_sorted, mock_print, mock_color_ok, mock_color_error)[source]¶
When we have hosts and their state is not specified, we expect them to be considered a pass and the display method to be called with appropriate arguments. The final call to print function is not an ideal place for assertion, as the string might get localised and/or adjusted in the future.
- test_v2_playbook_on_stats_no_hosts(mock_display, mock_print, mock_color_ok, mock_color_error)[source]¶
In case we don’t supply any hosts, we expect the method not to call display or related methods and attributes even once. The final call to print function is not an ideal place for assertion, as the string might get localised and/or adjusted in the future.
- test_v2_playbook_on_stats_some_fail(mock_callback_base, mock_display, mock_sorted, mock_print, mock_color_ok, mock_color_error)[source]¶
When at least one host is specified as failure and/or unreachable we expect it to be considered a failure and the display method to be called with the appropriate arguments in the proper order. The final call to print function is not an ideal place for assertion, as the string might get localised and/or adjusted in the future.
- test_v2_runner_on_failed_no_result(mock_print, mock_dump_results)[source]¶
The test asserts on argumets passed to print_failure_message method. In order to check the call arguments we need initialize them before passing the mock_results to the tested method. It is a bit hacky, but the most simple way I know how to make sure the relevant mocks ids don’t change. If you know how to improve it, go for it.
- test_v2_runner_on_failed_one_result(mock_print, mock_dump_results)[source]¶
The test asserts on argumets passed to print_failure_message method. In order to check the call arguments we need initialize them before passing the mock_results to the tested method. It is a bit hacky, but the most simple way I know how to make sure the relevant mocks ids don’t change. If you know how to improve it, go for it.
- test_v2_runner_on_ok_debug_msg(mock_display, mock_dump_results, mock_debug_template, mock_ok_color)[source]¶
The test asserts on argumets passed to print_failure_message method. In order to check the call arguments we need initialize them before passing the mock_results to the tested method. It is a bit hacky, but the most simple way I know how to make sure the relevant mocks ids don’t change. If you know how to improve it, go for it.
- test_v2_runner_on_ok_debug_vars(mock_display, mock_dump_results, mock_debug_template, mock_ok_color)[source]¶
The test asserts on argumets passed to print_failure_message method. In order to check the call arguments we need initialize them before passing the mock_results to the tested method. It is a bit hacky, but the most simple way I know how to make sure the relevant mocks ids don’t change. If you know how to improve it, go for it.
- test_v2_runner_on_ok_warnings(mock_display, mock_dump_results, mock_warn_template, mock_error_color)[source]¶
The test asserts on argumets passed to print_failure_message method. In order to check the call arguments we need initialize them before passing the mock_results to the tested method. It is a bit hacky, but the most simple way I know how to make sure the relevant mocks ids don’t change. If you know how to improve it, go for it.
- test_v2_runner_on_unreachable(mock_print)[source]¶
The test asserts on argumets passed to print_failure_message method. In order to check the call arguments we need initialize them before passing the mock_results to the tested method. It is a bit hacky, but the most simple way I know how to make sure the relevant mocks ids don’t change. If you know how to improve it, go for it.