Skip to content

Add CacheTest for dataprovider issue 3236 #3237

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

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

baflQA
Copy link
Contributor

@baflQA baflQA commented Jul 14, 2025

Introduces a new test class to verify dataprovider behavior with retries and caching disabled. The test ensures unique data per retry and validates invocation count.

Fixes # .

Did you remember to?

  • Add test case(s)
  • Update CHANGES.txt
  • Auto applied styling via ./gradlew autostyleApply

We encourage pull requests that:

  • Add new features to TestNG (or)
  • Fix bugs in TestNG

If your pull request involves fixing SonarQube issues then we would suggest that you please discuss this with the
TestNG-dev before you spend time working on it.

Note: For more information on contribution guidelines please make sure you refer our Contributing section for detailed set of steps.

Summary by CodeRabbit

  • Tests
    • Added new tests to verify data provider behavior with retries and caching disabled.
    • Introduced a test to ensure fresh data is returned when tests are retried.

Introduces a new test class to verify dataprovider behavior with retries and caching disabled. The test ensures unique data per retry and validates invocation count.
Copy link

coderabbitai bot commented Jul 14, 2025

Walkthrough

A new test class, CacheTest, has been added to the test suite. It introduces a test method using a data provider that generates unique UUIDs and a custom retry analyzer. The data provider disables caching for retries, and the test logic tracks invocation and retry counts to control test flow and assertions. Additionally, a new test method in DataProviderTest runs CacheTest and verifies the retry behavior results.

Changes

File(s) Change Summary
testng-core/src/test/java/test/dataprovider/issue3236/CacheTest.java Added CacheTest class with a test method, a data provider generating UUIDs, and a retry analyzer.
testng-core/src/test/java/test/dataprovider/DataProviderTest.java Added testDataProviderReturnsFreshDataWhenTestRetried method that runs CacheTest and asserts test retry outcomes.

Sequence Diagram(s)

sequenceDiagram
    participant TestRunner
    participant CacheTest
    participant DataProvider
    participant MyRetry

    TestRunner->>CacheTest: Run testMethod (with DataProvider)
    CacheTest->>DataProvider: getData()
    DataProvider-->>CacheTest: New UUID (no cache on retry)
    CacheTest->>CacheTest: Assert UUID, increment counters
    alt Assertion fails & retry allowed
        CacheTest->>MyRetry: retry()
        MyRetry-->>TestRunner: true (allow retry)
        TestRunner->>CacheTest: Retry testMethod (new UUID)
    else Assertion passes or retries exhausted
        MyRetry-->>TestRunner: false (stop retry)
    end
Loading

Poem

A test with a twist, a UUID anew,
Each retry brings something fresh to pursue.
With counters and checks, the logic is tight,
The rabbit hops on, ensuring it’s right.
🐇✨

Here’s to retries and data uncached—
Another bug’s journey, thoroughly matched!


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c3dd828 and c3519b9.

📒 Files selected for processing (1)
  • testng-core/src/test/java/test/dataprovider/DataProviderTest.java (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • testng-core/src/test/java/test/dataprovider/DataProviderTest.java
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)
  • GitHub Check: 24, oracle, ubuntu, Pacific/Chatham, fr_FR, stress JIT
  • GitHub Check: 11, liberica, ubuntu, Pacific/Chatham, ru_RU
  • GitHub Check: 21, microsoft, ubuntu, Pacific/Chatham, ru_RU, stress JIT
  • GitHub Check: 21, oracle, macos, Pacific/Chatham, de_DE
  • GitHub Check: 21, oracle, macos, Pacific/Chatham, tr_TR, stress JIT
  • GitHub Check: 17, temurin, windows, Pacific/Chatham, tr_TR
  • GitHub Check: 21, liberica, same hashcode, macos, Pacific/Chatham, fr_FR
✨ Finishing Touches
  • 📝 Generate Docstrings

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (2)
testng-core/src/test/java/test/dataprovider/issue3236/CacheTest.java (2)

14-15: Consider test isolation and thread safety concerns.

The static invocationCount and instance field currentUuid could cause issues:

  • Static state persists across test runs, potentially affecting test isolation
  • currentUuid is not thread-safe, though this may be acceptable for sequential test execution

Consider using TestNG's @BeforeMethod to reset state or making the test more self-contained:

public class CacheTest {
-  public static final AtomicInteger invocationCount = new AtomicInteger(0);
+  private final AtomicInteger invocationCount = new AtomicInteger(0);
   private String currentUuid;

17-23: Test logic is correct but could be clearer.

The test successfully validates that the data provider is called on retry when cacheDataForTestRetries = false, but the logic is somewhat convoluted with the hardcoded invocation count check.

Consider adding a comment to explain the test flow:

  @Test(dataProvider = "dp", retryAnalyzer = MyRetry.class)
  public void testMethod(String uuid) {
+    // Verify that fresh UUID is generated on each retry (no caching)
     assertEquals(currentUuid, uuid);
+    // Fail on first invocation to trigger retry, pass on second
     if (invocationCount.get() != 2) {
       throw new RuntimeException("Failed for " + uuid);
     }
   }
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d50b2ad and e4b2c06.

📒 Files selected for processing (1)
  • testng-core/src/test/java/test/dataprovider/issue3236/CacheTest.java (1 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: krmahadevan
PR: testng-team/testng#3181
File: testng-core/src/test/java/test/invocationcount/issue3180/RetryAnalyzer.java:6-9
Timestamp: 2024-09-30T05:21:21.304Z
Learning: In test code for the TestNG project, it's acceptable to hardcode parameters like `retryLimit` since they don't need to be configurable.
Learnt from: krmahadevan
PR: testng-team/testng#3181
File: testng-core/src/test/java/test/invocationcount/issue3180/RetryAnalyzer.java:6-9
Timestamp: 2024-10-09T09:04:04.750Z
Learning: In test code for the TestNG project, it's acceptable to hardcode parameters like `retryLimit` since they don't need to be configurable.
Learnt from: juherr
PR: testng-team/testng#3171
File: testng-core/src/test/java/test/invocationcount/issue1719/TestclassSample.java:24-45
Timestamp: 2024-09-05T07:53:27.213Z
Learning: When suggesting improvements to test code, encapsulating complex or repetitive logic into separate methods can enhance readability and maintainability. Additionally, logging important messages before assertions can improve the debugging experience by ensuring that the details are captured in the test output.
Learnt from: juherr
PR: testng-team/testng#3171
File: testng-core/src/test/java/test/invocationcount/issue1719/TestclassSample.java:24-45
Timestamp: 2024-10-09T09:04:04.750Z
Learning: When suggesting improvements to test code, encapsulating complex or repetitive logic into separate methods can enhance readability and maintainability. Additionally, logging important messages before assertions can improve the debugging experience by ensuring that the details are captured in the test output.
testng-core/src/test/java/test/dataprovider/issue3236/CacheTest.java (4)
Learnt from: krmahadevan
PR: testng-team/testng#3181
File: testng-core/src/test/java/test/invocationcount/issue3180/RetryAnalyzer.java:6-9
Timestamp: 2024-09-30T05:21:21.304Z
Learning: In test code for the TestNG project, it's acceptable to hardcode parameters like `retryLimit` since they don't need to be configurable.
Learnt from: krmahadevan
PR: testng-team/testng#3181
File: testng-core/src/test/java/test/invocationcount/issue3180/RetryAnalyzer.java:6-9
Timestamp: 2024-10-09T09:04:04.750Z
Learning: In test code for the TestNG project, it's acceptable to hardcode parameters like `retryLimit` since they don't need to be configurable.
Learnt from: krmahadevan
PR: testng-team/testng#3181
File: testng-core/src/test/java/test/invocationcount/FailedInvocationCountTest.java:183-215
Timestamp: 2024-10-01T05:35:26.176Z
Learning: Prefer keeping test data methods duplicated for better understanding and readability, even if it introduces duplication.
Learnt from: krmahadevan
PR: testng-team/testng#3181
File: testng-core/src/test/java/test/invocationcount/FailedInvocationCountTest.java:183-215
Timestamp: 2024-10-18T04:03:57.942Z
Learning: Prefer keeping test data methods duplicated for better understanding and readability, even if it introduces duplication.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)
  • GitHub Check: 21, oracle, ubuntu, Pacific/Chatham, fr_FR, stress JIT
  • GitHub Check: 21, oracle, ubuntu, UTC, de_DE
  • GitHub Check: 11, temurin, same hashcode, macos, Pacific/Chatham, fr_FR, stress JIT
  • GitHub Check: 24, oracle, same hashcode, windows, America/New_York, de_DE, stress JIT
  • GitHub Check: 17, temurin, windows, UTC, tr_TR
  • GitHub Check: 11, corretto, windows, America/New_York, fr_FR, stress JIT
  • GitHub Check: 11, liberica, windows, UTC, de_DE, stress JIT
🔇 Additional comments (2)
testng-core/src/test/java/test/dataprovider/issue3236/CacheTest.java (2)

25-30: Data provider implementation correctly tests the core functionality.

The cacheDataForTestRetries = false setting and UUID generation on each invocation properly tests the intended behavior.


32-40: Retry analyzer implementation is correct and follows TestNG patterns.

The retry logic correctly allows one retry attempt, which aligns with the test's expectation of 2 total invocations.

Note: Based on retrieved learnings, hardcoded retry limits are acceptable in TestNG test code since they don't need to be configurable.

baflQA added 2 commits July 14, 2025 12:51
Updated the visibility of the invocationCount field from public static to private in CacheTest to improve encapsulation and restrict access.
Copy link
Member

@juherr juherr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't follow undocumented convention for tests.
Here you have a sample that should be used by a test which is running the engine.
Please check how are run samples in current tests.

@baflQA
Copy link
Contributor Author

baflQA commented Jul 14, 2025

It doesn't follow undocumented convention for tests. Here you have a sample that should be used by a test which is running the engine. Please check how are run samples in current tests.

Sorry? I'm afraid that I did not get You.

I basically used this https://github.com/testng-team/testng/blob/823799c833aa6e6f47c91996b09dcbba3b931b17/testng-core/src/test/java/test/dataprovider/issue3041/SampleTestCase.java as a template for the reproduction of the issue I just reported.

Do You want me to invoke this test from TestNG instance like this? https://github.com/testng-team/testng/blob/823799c833aa6e6f47c91996b09dcbba3b931b17/testng-core/src/test/java/test/dataprovider/issue3041/SampleTestCase.java

Copy link
Member

@krmahadevan krmahadevan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please do the following ?

  • Create a new test method within test.dataprovider.DataProviderTest that creates TestNG instance and then uses this CacheTest class internally and runs assertions

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
testng-core/src/test/java/test/dataprovider/DataProviderTest.java (1)

721-728: Verify the expected test behavior and consider adding more descriptive assertions.

The test logic appears correct and follows the established pattern. However, to ensure the test validates the intended behavior, verify that:

  1. The retry mechanism correctly marks the first failed attempt as skipped
  2. The fresh data generation is actually being tested (though this is implicitly verified by the CacheTest implementation)

Consider adding more descriptive assertion messages to make test failures clearer:

-    assertThat(tla.getFailedTests()).size().isEqualTo(0);
-    assertThat(tla.getSkippedTests()).size().isEqualTo(1);
+    assertThat(tla.getFailedTests()).withFailMessage("Expected no failed tests after retry").size().isEqualTo(0);
+    assertThat(tla.getSkippedTests()).withFailMessage("Expected exactly one skipped test due to retry").size().isEqualTo(1);
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1311cd3 and c3dd828.

📒 Files selected for processing (1)
  • testng-core/src/test/java/test/dataprovider/DataProviderTest.java (2 hunks)
🧰 Additional context used
🧠 Learnings (1)
testng-core/src/test/java/test/dataprovider/DataProviderTest.java (4)
Learnt from: krmahadevan
PR: testng-team/testng#3181
File: testng-core/src/test/java/test/invocationcount/issue3180/RetryAnalyzer.java:6-9
Timestamp: 2024-10-09T09:04:04.750Z
Learning: In test code for the TestNG project, it's acceptable to hardcode parameters like `retryLimit` since they don't need to be configurable.
Learnt from: krmahadevan
PR: testng-team/testng#3181
File: testng-core/src/test/java/test/invocationcount/issue3180/RetryAnalyzer.java:6-9
Timestamp: 2024-09-30T05:21:21.304Z
Learning: In test code for the TestNG project, it's acceptable to hardcode parameters like `retryLimit` since they don't need to be configurable.
Learnt from: krmahadevan
PR: testng-team/testng#3181
File: testng-core/src/test/java/test/invocationcount/FailedInvocationCountTest.java:183-215
Timestamp: 2024-10-18T04:03:57.942Z
Learning: Prefer keeping test data methods duplicated for better understanding and readability, even if it introduces duplication.
Learnt from: krmahadevan
PR: testng-team/testng#3181
File: testng-core/src/test/java/test/invocationcount/FailedInvocationCountTest.java:183-215
Timestamp: 2024-10-01T05:35:26.176Z
Learning: Prefer keeping test data methods duplicated for better understanding and readability, even if it introduces duplication.
🧬 Code Graph Analysis (1)
testng-core/src/test/java/test/dataprovider/DataProviderTest.java (1)
testng-core/src/test/java/test/dataprovider/issue3236/CacheTest.java (1)
  • CacheTest (12-41)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)
  • GitHub Check: 24, oracle, macos, America/New_York, ru_RU, stress JIT
  • GitHub Check: 11, corretto, windows, America/New_York, fr_FR, stress JIT
  • GitHub Check: 24, oracle, ubuntu, Pacific/Chatham, ru_RU
  • GitHub Check: 24, oracle, ubuntu, America/New_York, ru_RU
  • GitHub Check: 11, zulu, windows, UTC, tr_TR, stress JIT
  • GitHub Check: 17, zulu, ubuntu, Pacific/Chatham, de_DE, stress JIT
  • GitHub Check: 21, microsoft, same hashcode, macos, Pacific/Chatham, fr_FR, stress JIT
🔇 Additional comments (1)
testng-core/src/test/java/test/dataprovider/DataProviderTest.java (1)

64-64: LGTM!

The import statement correctly references the new test class and follows the established pattern.

Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
@baflQA
Copy link
Contributor Author

baflQA commented Jul 17, 2025

Done, I suppose

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants