Skip to content
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

BugChecker for effectively unused PublisherProbes #421

Open
1 of 4 tasks
werli opened this issue Dec 20, 2022 · 0 comments
Open
1 of 4 tasks

BugChecker for effectively unused PublisherProbes #421

werli opened this issue Dec 20, 2022 · 0 comments

Comments

@werli
Copy link
Member

werli commented Dec 20, 2022

Problem

Reactor's PublisherProbe defines a neat API to test reactive code. However, it is only helpful when it is actually used.

Considering the following code snippet, the PublisherProbe is initialized and asserted, but never actually used. Surely we can assert that it was never subscribed to, because we never included it in code that should be subscribed to. 🙂

@Test
void probeBugChecker() {
    PublisherProbe<Void> probe = PublisherProbe.empty();
    // some test code that doesn't involve `probe`
    probe.assertWasNotSubscribed();
}

This looks like an unintentional human mistake that wrongfully could increase the author's confidence in their production code.

Description of the proposed new feature

  • Support a stylistic preference.
  • Avoid a common gotcha, or potential problem.
  • Improve performance.

I'd like to have a BugChecker that identifies such a construct as a common mistake and expects changes.

Considerations

In essence, this BugChecker should flag in the following scenario:

  1. A PublisherProbe is declared and initialized
  2. Is used exclusively in assertion calls (e.g. PublisherProbe#assertWasNotSubscribed).

The BugChecker should not flag if

  • The PublisherProbe is used
    • as a mocked value with PublisherProbe#{mono,flux}
    • as a parameter to a method, since it could be used for mocking there

Participation

  • I am willing to submit a pull request to implement this improvement.

Most likely not within the next couple of weeks.

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

No branches or pull requests

1 participant