-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
macOS test added #5264
macOS test added #5264
Conversation
3a1f915
to
2c925fa
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pro-akim
Please check the suggested changes.
return data['platform'] | ||
else: | ||
raise KeyError("The 'platform' key was not found in the YAML file.") | ||
except FileNotFoundError: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The exception handling block logs the exception but does not raise it again. If the exception handling does not raise the exception, the testing module will continue without returning an error exit code to the workflow_engine.
The workflow will not abort all the tasks if the returned exit code is 0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be fixed as an improvement in a future process where obtaining the os_type variable is obtained from a single call and not using constant calls to the disk file
return data['arch'] | ||
else: | ||
raise KeyError("The 'platform' key was not found in the YAML file.") | ||
except FileNotFoundError: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I make the same observation to this exception handling block.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be fixed as an improvement in a future process where obtaining the os_type variable is obtained from a single call and not using constant calls to the disk file
@@ -71,8 +71,7 @@ def test_service(wazuh_params): | |||
GeneralComponentActions.component_stop(agent_params, 'wazuh-agent') | |||
|
|||
for agent_names, agent_params in wazuh_params['agents'].items(): | |||
assert 'inactive' in GeneralComponentActions.get_component_status(agent_params, 'wazuh-agent'), logger.error(f'{agent_names} is still active by command') | |||
assert not GeneralComponentActions.isComponentActive(agent_params, 'wazuh-agent'), logger.error(f'{agent_names} is still active by command') | |||
assert 'inactive' in GeneralComponentActions.get_component_status(agent_params, 'wazuh-agent') or 'not running' in GeneralComponentActions.get_component_status(agent_params, 'wazuh-agent'), logger.error(f'{agent_names} is still active by command') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't recommend to call logger.error
in assert statements. The second argument is the message assigned to the AssertionError exception. If you use logger.error
, the return will be None, which will be the exception's message. Here's an example of what is the problem:
>>> import logging
>>> logger = logging.getLogger()
>>> assert False, logger.error('Error Message')
Error Message
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AssertionError: None
>>> assert False, 'Error Message'
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AssertionError: Error Message
Is it required to log the error? Pytest shows all the failures in the output report.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The correctness of all asserts can be evaluated as a proposal for improvement since all test assertions are developed with that structure.
TESTSI've run the test In the first run, the workflow file successfully allocated and provisioned the manager but failed to allocate the macOS agent. After investigating the issue, I've found that the allocator modules require the installation of the The macOS agent was allocated ok, and the testing task passed without failures. workflow.log
I've run the test All the agent tests passed with no failures. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After a meeting with @pro-akim, we discussed the requested changes and arrived at the following decisions:
-
Exception blocks in
deployability/modules/testing/tests/helpers/generic.py
Many tests are using theHostInformation.get_os_type
method. The current implementation reads the track file. A better solution is to open the YAML file, convert it into a dictionary or an object, and reimplement the function to access the object instead of the file. We'll create a new issue to implement this procedure. -
assertions and log
- We will replace the calls to
logger.error
with a string message in all theassert
statements.
We must define whether to send an error message to the log when the assert conditions are false. Pytest tests send the errors to the final report; the test doesn't need to duplicate the report. - We will create a new enhancement-type issue to implement the above bullets.
- We will replace the calls to
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The requested changes will be addressed in deferred issues as points of improvement
@@ -71,8 +71,7 @@ def test_service(wazuh_params): | |||
GeneralComponentActions.component_stop(agent_params, 'wazuh-agent') | |||
|
|||
for agent_names, agent_params in wazuh_params['agents'].items(): | |||
assert 'inactive' in GeneralComponentActions.get_component_status(agent_params, 'wazuh-agent'), logger.error(f'{agent_names} is still active by command') | |||
assert not GeneralComponentActions.isComponentActive(agent_params, 'wazuh-agent'), logger.error(f'{agent_names} is still active by command') | |||
assert 'inactive' in GeneralComponentActions.get_component_status(agent_params, 'wazuh-agent') or 'not running' in GeneralComponentActions.get_component_status(agent_params, 'wazuh-agent'), logger.error(f'{agent_names} is still active by command') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The correctness of all asserts can be evaluated as a proposal for improvement since all test assertions are developed with that structure.
return data['arch'] | ||
else: | ||
raise KeyError("The 'platform' key was not found in the YAML file.") | ||
except FileNotFoundError: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be fixed as an improvement in a future process where obtaining the os_type variable is obtained from a single call and not using constant calls to the disk file
return data['platform'] | ||
else: | ||
raise KeyError("The 'platform' key was not found in the YAML file.") | ||
except FileNotFoundError: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be fixed as an improvement in a future process where obtaining the os_type variable is obtained from a single call and not using constant calls to the disk file
Adding features for macOs agent testing