Test methods without assertions are problematic for several reasons:
First, they provide no actual validation of the code being tested. A test that executes code but doesn’t verify the results gives a false sense of
security - it appears that the code is tested, but no actual verification occurs.
Second, missing assertions often indicate incomplete test implementation. Developers may have written the setup code but forgotten to add the
verification logic, leaving the test in an unfinished state.
Third, such tests can hide real issues. If the tested code throws an exception, the test will fail, but if it completes without error, the test
passes regardless of whether the behavior is correct.
Finally, tests without assertions make it harder to understand what behavior is being verified, reducing the documentation value of the test
suite.
Exceptions
The following patterns are considered valid and will not trigger this rule:
- Tests using framework-specific assertion blocks (e.g., Spock’s
then:, expect:, or where: blocks)
- Tests explicitly marked as disabled (e.g.,
@Test(enabled=false) in TestNG)
- Tests that delegate verification to helper methods that encapsulate assertions
What is the potential impact?
Tests without assertions provide no actual verification of code behavior, leading to false confidence in test coverage. This can allow bugs to go
undetected and makes it difficult to catch regressions when code changes.
