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>
From #1758 (comment)
There are 1774
Assert.assertTrue(...)and and 601Assert.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:
If there was a failure in this scenario it would look like
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>