FP on java:S5976

Hello,

I used to have a couple test classes with lots of methods following exactly the same model:

class MyTest {
  @Test
  public void test01() {
    var code = "line1\nline2\nline3";
    var expected = "line1\nline3";
    assertThat(func(code)).isEqualTo(expected);
  }
  @Test
  public void test02() {
    var code = "another value";
    var expected = "another expect value";
    assertThat(func(code)).isEqualTo(expected);
  }
}

I’ve changed one test class to use multi-line strings, and I now have issues reported from rule S5976:

class MyTest {
  @Test
  public void test01() {
    var code = """
         line1
         line2
         line3
         """;
    var expected = """
         line1
         line3
         """;
    assertThat(func(code)).isEqualTo(expected);
  }
}

There’s no way to have a parameterized test here, or at least not any convenient way. Not sure why multi-line strings are handled differently from single-line strings.

  • Java Language
  • Rule: S5976 (Similar tests should be grouped in a single Parameterized test)
  • SonarQube Server EE 2026.3.1

Gilles

Hi @giles45,

At least for the brief snippet you shared, I believe it should be possible to parameterize it with something like @ParameterizedTest and @MethodSource for example, in regards to the snippet, do you also agree that it wouldn’t really be a false positive?

Now, I guess your actual code is not as straightforward, so there it might be justified to claim that it’s a false positive. Could you share a bit more about why you think the rule shouldn’t consider it as parameterizable?

Regardless of this, I understand that part of the problem is also that before your change, the rule wasn’t triggering, but now it is. I see your point there! It’s possible that the issue was pre-existing but marked as “accepted”, “false positive”, etc. but was reopened because of this change. Could you check the issue’s Activity tab?

@andres Sorry for the late answer, didn’t see your message.

My point is that the rule didn’t trigger an issue with single line strings (they were never accepted, it’s just no issue were raised at all). Making the code easier to read by switching to multiline strings raise an issue.

Having a parameterized test doesn’t really improved readability in this case.

Hey @gquerret, I would like to clarify: is the issue showing that the test with the multi-line string should be parameterized alongside the ones with the single-line strings? I tried to reproduce this but it doesn’t pop up for me. Do you think you could create a reproducer that you could share and that raises the issue for you?

Just tried to create a simple example, but couldn’t reproduce for now (issue is raised in both cases) :grimacing: I’ll try to see which exact test case I was working on when I wrote the initial post.