2

Let's say we have a project full of unit tests (thousands) and they all should look like this

@Test
public void testExceptionInBla() {
   // some test
}

But in one case someone forgot to put an @Test decorator on top of the test.

What would be an easy way to spot those tests, without looking through all the code manually?

I want to find code like this, it's a test without @Test:

public void testExceptionInBla() {
   // some test
}
Veslav
  • 466
  • 1
  • 5
  • 14
  • I would create a perl or python script that lists all occurences of `/\stest[A-Z]/` where current or previous line does not contain `@Test`. This list should be small enough to visit and fix all of them. – rsp Feb 26 '20 at 10:28

2 Answers2

3

I were you I would look at some Sonar rule here I found something that may can match requirement:

https://rules.sonarsource.com/java/RSPEC-2187

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
1

But in one case someone forgot to put an @Test decorator on top of the test.

And

I want to find code like this, it's a test without @Test:

public void testExceptionInBla() { // some test }

Annotating the method with @Test or specifying a test prefix in the method name is about the same thing in terms of consequences if the developer forgets to do that.
If the @Test is the way today, that is not chance.
The @Test annotation brings two real advantages on the test prefix :

1) it is checked at compile test. For example @Tast will provoke a compilation error while tastWhen...() will not.

2) @Test makes the test method name more straight readable : it allows to focus on the scenario with a functional language. should_throw_exception_if_blabla() sounds more meaningful than test_should_throw_exception_if_blabla().

About your issue : how to ensure that tests are effectively executed, I would take things in another way. Generally you want to ensure that unit tests execution covers a minimum level of the application source code (while you can go down at package or class level if makes sense).
And that is the coverage tools goal (Jacoco for example) to do that job. You can even add rules to make the build fail if the level of coverage of classes belonging to some package are not covered at least at a specified minimum level (look at that post).


Small Adding :
If you really ensure that methods of test are correctly annotated, you have a way :
1) you have to choose a convention for test methods : for example all instance and not private methods in a test class are test methods.
2) Create a Sonar rule that retrieves all non private instance methods of test classes and ensure that all these methods are annotated with @Test.
3) Add that rule to your Sonar rules.

davidxxx
  • 125,838
  • 23
  • 214
  • 215