홈

Unit 테스트를 하나 이상의 테스트와 관련된 어노테이션과 함께 시작하는 것은 쓸모없을 뿐 아니라 테스트 실패하거나 원하지 않는 부작용과 같은 사이드 이펙트가 발생할 수 있습니다. 이 룰은 테스트 방법에 다음과 같은 유사한 기능의 어노테이션이 둘 이상 포함된 경우 알려줍니다. @Test @RepeatedTest @ParameterizedTest @TestFactory @TestTemplate 규칙을 어긴 코드 @Test @RepeatedTest(2) // 규칙을 어긴 코드, 이 테스트는 3번 반복하게 될 것 입니다. void test() { } @ParameterizedTest @Te...

만약 테스트를 작성하기 위해 어떤 클래스의 private 제한자가 아닌 모든 함수를 Mocking 했다면, 그것은 테스트가 너무 복잡해졌거나 Mocking 작동 방식을 잘못 이해했다는 것입니다. 테스트 코드를 여러 유닛으로 리팩터링 하거나 직접 인스턴스화 하여 클래스 자체를 사용하는 것을 고려해야 합니다. 또는 테스트하고자 하는 클래스를 상속하는 클래스를 새로 만들어 사용하는 것을 고려해야 합니다. 이 룰은 주어진 클래스의 모든 멤버를 mocking 한 경우 알려줍니다. 규칙을 어긴 코드 @Test void test_requiring_MyClass() { MyClass myClassMock = mock...

JUnit3에서 JUni4 또는 JUnit5로 마이그레이션 할 때, 동일한 동작을 유지하려면 setUp()과 tearDown() 함수(JUnit3에서 각 테스트 전후에 코드를 실행하기 위해 처음 도입됨)는 올바른 어노테이션으로 시작되어야 합니다. 이 룰은 테스트 클래스에서 setUp()와 tearDown() 함수가 어노테이션으로 시작되지 않았을 때 알려줍니다. 규칙을 어긴 코드 JUnit4: @Test public void setUp() { ... } // 규칙을 어긴 코드; @Before 어노테이션으로 시작해야 합니다. public void tearDown() { ... } // 규칙을 어긴 코드...

JUnit assertions는 Runnable의 run 함수로 만들어지면 안됩니다. 왜냐하면 실패한 assertions 결과는 AssertionErrors 에러로 던져지기 때문입니다. 테스트를 실행한 스레드가 아닌 다른 스레드에서 오류가 발생하면 스레드가 종료되지만 테스트는 실패하지 않습니다. 규칙을 어긴 코드 JUnit4: public void run() { // ... Assert.assertEquals(expected, actual); // 규칙을 어긴 코드 } If you like SONARKUBE, don’t forget to give me a star. ...

코드에서 발생할 수 있는 예외를 검증할 때, 모범 사례는 테스트 코드에서 여러 개의 함수 호출을 피하고 무엇이 테스트돼야 하는지 명확히 하는 것 입니다. 두개의 함수가 같은 checked exception을 일으킬 수 있을 때, 정말로 테스트하고자 하는 것이 무엇인지 알 수 없기 때문에 이 모범 사례를 존중하지 않는 것은 버그입니다. 테스트 코드에서 오직 하나의 함수만이 예상되는 checked exception을 일으키도록 해야합니다. 규칙을 어긴 코드 @Test public void testG() { // g() 또는 f() 함수 중 하나가 예외를 던질 것이라고 예상하십니까? assertTh...

Assertion 함수는 “java.lang.AssertionError”. 예외를 던집니다. 만약 Assertion 함수 호출이 try-catch 구문의 try 블럭에서 유사한 에러가 잡히며 끝나는 경우, 예외의 일부 속성을 테스트해야 합니다. 그렇지 않으면 assertion이 절대 실패하지 않습니다. 규칙을 어긴 코드 @Test public void should_throw_assertion_error() { try { throwAssertionError(); Assert.fail("Expected an AssertionError!"); // 규칙을 어긴 코드, 'Assert...

호환되지 않는 타입을 비교하는 Assertions는 항상 실패합니다. 그리고 negative assertions는 항상 통과합니다. 최악의 경우, 개발자는 잘못된 assertion을 알아차리기 전에 코드 논리를 수정하는 데 시간을 낭비합니다. 호환되지 않는 타입은 다음과 같습니다: primitive 타입을 null과 비교 객체를 관련없는 primitive 타입과 비교 관련 없는 클래스들 간 비교 array와 non-array 간 비교 서로 다른 유형의 두 array 간 비교 이 룰은 negative assertions에서 서로 관련 없는 클래스와 인터페이스 또는 관련 없는 인터페이스 타입...

만약 @Nest 어노테이션을 붙이지 않는다면, 테스트를 포함한 내부 클래스는 테스트가 실행되는 동안 실행되지 않습니다. IDE에서 테스트를 수동으로 실행할 수는 있지만 빌드 중에는 그렇지 않습니다. 반면에 테스트를 포함한 정적 내부 클래스는 @Nest 어노테이션을 붙이면 안됩니다. JUnit5는 해당 포함 클래스의 인스턴스와 설정 및 상태를 공유하지 않습니다. 이 룰은 잘못된 @Nested 어노테이션이 있는 JUNit5 테스트 메서드를 포함하는 내부 클래스 및 정적 중첩 클래스에 알려줍니다. Note: 이 룰은 기본 설정을 사용하는 케이스에 JUNit 5가 실행 중인 컨텍스트(예: Maven Surefire...