-
Notifications
You must be signed in to change notification settings - Fork 358
[Feature] Reduce the amount of assertTrue/False statements #1762
Copy link
Copy link
Open
Labels
enhancementNew feature or requestNew feature or requesttest fixtest fixestest fixestriagedIssues labeled as 'Triaged' have been reviewed and are deemed actionable.Issues labeled as 'Triaged' have been reviewed and are deemed actionable.
Description
From #1758 (comment)
There are 1774 Assert.assertTrue(...) and and 601 Assert.assertFalse(...) statements in this codebase that are not very useful for debugging test failures. We should transition to alternatives that make test failures easier to diagnose and make tests more readable.
Consider a test case structured like this:
final String responseBody = httpClient.sendRequest('GET', '_cat');
Assert.assertTrue(body.contains("forbidden"))'
If there was a failure in this scenario it would look like
org.opensearch.security.Test > testCatApiForbidden FAILED
org.opentest4j.AssertionFailedError: expected: <true> but was: <false>
at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:40)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:35)
at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:162)
at app//org.opensearch.security.Test.testCatApiForbidden (Test.java:107)
It would be much better if the test was structured in a way that made it clearer what was wrong such as an error like org.opentest4j.AssertionFailedError: expected: <HttpStatusCode.Forbidden> but was: <HttpStatusCode.NotFound>
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
enhancementNew feature or requestNew feature or requesttest fixtest fixestest fixestriagedIssues labeled as 'Triaged' have been reviewed and are deemed actionable.Issues labeled as 'Triaged' have been reviewed and are deemed actionable.