opensearch-sdk-java
opensearch-sdk-java copied to clipboard
[FEATURE] Create SDKTestCase and SDKIntegTestCase classes
Is your feature request related to a problem?
Inheriting from OpenSearchTestCase brings with it lots of methods we can use, but some cause errors. For example, the random test code fails:
String foo = randomAlphaOfLength(5);
results in
java.lang.IllegalStateException: No context information for thread: Thread[id=1, name=Test worker, state=RUNNABLE, group=main]. Is this thread running under a class com.carrotsearch.randomizedtesting.RandomizedRunner runner context? Add @RunWith(class com.carrotsearch.randomizedtesting.RandomizedRunner.class) to your test class. Make sure your code accesses random contexts within @BeforeClass and @AfterClass boundary (for example, static test class initializers are not permitted to access random contexts).
at com.carrotsearch.randomizedtesting.RandomizedContext.context(RandomizedContext.java:249)
at com.carrotsearch.randomizedtesting.RandomizedContext.current(RandomizedContext.java:134)
at com.carrotsearch.randomizedtesting.RandomizedTest.getContext(RandomizedTest.java:74)
at com.carrotsearch.randomizedtesting.RandomizedTest.getRandom(RandomizedTest.java:94)
at com.carrotsearch.randomizedtesting.RandomizedTest.randomAsciiLettersOfLength(RandomizedTest.java:575)
at com.carrotsearch.randomizedtesting.RandomizedTest.randomAsciiOfLength(RandomizedTest.java:561)
at org.opensearch.test.OpenSearchTestCase.randomAlphaOfLength(OpenSearchTestCase.java:852)
Similarly the OpenSearchIntegTestCase has a client() method that returns a random client; we need to return SDKClient here.
What solution would you like?
Subclasses of OpenSearch(Integ)TestCase which override instance methods or replace static methods and restore the full functionality of these superclasses.
What alternatives have you considered?
Not using these superclasses and recreating the features we need ourselves, or not randomizing input, etc.
Do you have any additional context?
Lack of (thread) context appears to be one of the problems we're solving, so no.