Add AWSServices discard_regex integration tests

[fdalmaup]

Related issue
wazuh/wazuh#17388

Description

This PR adds new test cases for the discard_regex functionality, more precisely for the CloudWatchLogs and Inspector services.

Added

Tier 0

• discard_regex parameter tests for AWSCloudWatchLogs
• discard_regex parameter tests for AWSInspector

Testing performed

Tester	Test path	Jenkins	Local	OS	Commit	Notes
@fdalmaup (Developer)	tests/integration/test_aws/test_discard_regex.py	⚫⚫⚫	🟢	Ubuntu 22.04	e50f774	Nothing to highlight
@user (Reviewer)		⚫⚫⚫	🚫 🚫 🚫			Nothing to highlight

[EduLeon12]

After reviewing the proposed test cases I think they fulfill the development made, Therefore it's approved.

[Selutario]

Code changes LGTM. However, AWS ITs are available in 4.6.0 so the base branch can be changed. Also, take a look at the failing checks to fix them.

The base branch was changed.

[Selutario]

LGTM

[Selutario]

This PR can be merged once this issue is finished:

• Remove duplicated log in AWS integration after merging branches wazuh#18110

[Selutario]

Updating the changelog is required

[mauromalara]

I requested some changes but, for me, the most important things to be considered before proceeding with applying those changes are:

• I see that all test functions do the same and change minimal things like configuration or metadata. I would compress everything in a single test with different cases defined in a single YAML so that the test, according to these cases, knows what to validate and what not. If this is not possible, please detail what and why so that we can discuss about it.

• I do not see a test case that checks that the JSON field on which you want to filter does not exist (negative case).

• I don't see a validation to test for not discarding logs that don't apply to the filter set in <discard_regex> (negative case).

[fdalmaup]

Hi @mauromalara, regarding your comments:

I see that all test functions do the same and change minimal things like configuration or metadata. I would compress everything in a single test with different cases defined in a single YAML so that the test, according to these cases, knows what to validate and what not. If this is not possible, please detail what and why so we can discuss it.

The single YAML approach was tested, but due to the differences between the base configuration of the module for each case, these failed to execute as expected (e.g., for Cloudwatch having and not having the field attribute inside the discard_regex parameter depending on if it is JSON or simple text failed because it added an empty value for the --discard-field parameter to the module's execution).
What you mentioned could be analyzed in the tests migration issue.

I do not see a test case that checks that the JSON field you want to filter does not exist (negative case).

The test environment contains both JSON and simple text logs. If the JSON field does not exist, the module does not show any related message, it processes every available log without discarding them.

I don't see a validation to test for not discarding logs that don't apply to the filter set in <discard_regex> (negative case).

This is also related to the test environment mentioned previously, if more logs than expected were discarded due to unexpected behavior of the module, then the pattern defined in the tests should find more matches than the ones described in the test cases and fail.

[mauromalara]

The single YAML approach was tested, but due to the differences between the base configuration of the module for each case, these failed to execute as expected (e.g., for Cloudwatch having and not having the field attribute inside the discard_regex parameter depending on if it is JSON or simple text failed because it added an empty value for the --discard-field parameter to the module's execution).
What you mentioned could be analyzed in the wazuh/wazuh#17788.

Great! Please, update the issue you mentioned before to explicitly describe that you need to change this to reduce duplicated code.

The test environment contains both JSON and simple text logs. If the JSON field does not exist, the module does not show any related message, it processes every available log without discarding them.

In my view, I think this might not be good for the user. Picture this situation: as a user, what if I make a mistake while specifying the JSON field? Wouldn't it be preferable to promptly detect such issues by examining the logs? I suggest we create an issue on this matter and, furthermore, develop a test case to encompass this particular scenario.

This is also related to the test environment mentioned previously, if more logs than expected were discarded due to unexpected behavior of the module, then the pattern defined in the tests should find more matches than the ones described in the test cases and fail.

You're right, didn't think about it.

[mauromalara]

LGTM!

[fdalmaup]

Test execution 🟢

Three consecutive runs of the discard_regex ITs have been launched giving successful results:

====================================================================== test session starts ======================================================================
platform linux -- Python 3.10.12, pytest-7.1.2, pluggy-1.2.0
rootdir: /wazuh-qa/tests/integration, configfile: pytest.ini
plugins: testinfra-5.0.0, html-3.1.1, metadata-3.0.0
collected 17 items                                                                                                                                              

tests/integration/test_aws/test_discard_regex.py .................                                                                                        [100%]

------------------------------------------------------ generated html file: file:///wazuh-qa/report-1.html ------------------------------------------------------
================================================================ 17 passed in 330.45s (0:05:30) =================================================================
====================================================================== test session starts ======================================================================
platform linux -- Python 3.10.12, pytest-7.1.2, pluggy-1.2.0
rootdir: /wazuh-qa/tests/integration, configfile: pytest.ini
plugins: testinfra-5.0.0, html-3.1.1, metadata-3.0.0
collected 17 items                                                                                                                                              

tests/integration/test_aws/test_discard_regex.py .................                                                                                        [100%]

------------------------------------------------------ generated html file: file:///wazuh-qa/report-2.html ------------------------------------------------------
================================================================ 17 passed in 327.16s (0:05:27) =================================================================
====================================================================== test session starts ======================================================================
platform linux -- Python 3.10.12, pytest-7.1.2, pluggy-1.2.0
rootdir: /wazuh-qa/tests/integration, configfile: pytest.ini
plugins: testinfra-5.0.0, html-3.1.1, metadata-3.0.0
collected 17 items                                                                                                                                              

tests/integration/test_aws/test_discard_regex.py .................                                                                                        [100%]

------------------------------------------------------ generated html file: file:///wazuh-qa/report-3.html ------------------------------------------------------
================================================================ 17 passed in 324.24s (0:05:24) =================================================================

report-1.zip
report-2.zip
report-3.zip