Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • T ticket
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,809
    • Issues 1,809
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Administrator
  • ticket
  • Issues
  • #107

Closed
Open
Created Jan 12, 2022 by Administrator@rootMaintainer

Add at least one assertion to this test case.

Created by: armorcodegithubqa[bot]

A test case without assertions ensures only that no exceptions are thrown. Beyond basic runnability, it ensures nothing about the behavior of the code under test.

This rule raises an exception when no assertions from any of the following known frameworks are found in a test:

  • AssertJ
  • Awaitility
  • EasyMock
  • Eclipse Vert.x
  • Fest 1.x and 2.x
  • Hamcrest
  • JMock
  • JMockit
  • JUnit
  • Mockito
  • Rest-assured 2.0
  • RxJava 1.x and 2.x
  • Selenide
  • Spring's org.springframework.test.web.servlet.ResultActions.andExpect()
  • Truth Framework
  • WireMock

Furthermore, as new or custom assertion frameworks may be used, the rule can be parametrized to define specific methods that will also be considered as assertions. No issue will be raised when such methods are found in test cases. The parameter value should have the following format <FullyQualifiedClassName>#<MethodName>, where MethodName can end with the wildcard character. For constructors, the pattern should be <FullyQualifiedClassName>#<init>.

Example: com.company.CompareToTester#compare*,com.company.CustomAssert#customAssertMethod,com.company.CheckVerifier#<init>.

Noncompliant Code Example

@Test
public void testDoSomething() {  // Noncompliant
  MyClass myClass = new MyClass();
  myClass.doSomething();
}

Compliant Solution

Example when com.company.CompareToTester#compare* is used as parameter to the rule.

import com.company.CompareToTester;

@Test public void testDoSomething() { MyClass myClass = new MyClass(); assertNull(myClass.doSomething()); // JUnit assertion assertThat(myClass.doSomething()).isNull(); // Fest assertion }

@Test public void testDoSomethingElse() { MyClass myClass = new MyClass(); new CompareToTester().compareWith(myClass); // Compliant - custom assertion method defined as rule parameter CompareToTester.compareStatic(myClass); // Compliant }

File Path: src/test/java/io/armorcode/sqlinjection/SqlinjectionApplicationTests.java:10

https://qa.armorcode.ai/#/findings/6318907

Assignee
Assign to
Time tracking