JUnit ErrorCollector @Rule(예제 포함)

⚡ 스마트 요약

JUnit ErrorCollector는 테스트가 실패한 후에도 계속 실행되도록 하는 규칙으로, 테스트 메서드가 종료되는 대신 모든 오류 객체를 수집하여 한꺼번에 보고합니다.ping 첫 번째 문제에서.

  • 🔘 목적 : 어설션, 네트워크 또는 GUI 검사가 실패한 후에도 테스트를 계속 진행하고, 수집된 모든 오류를 한 번에 보고합니다.
  • ☑️ 선언: @Rule은 공개 비정적 ErrorCollector 필드에 적용됩니다. JUnit 각 테스트에 규칙을 적용합니다.
  • ✅ 수집: addError(Throwable)는 모든 Error 또는 Exception을 저장합니다. 왜냐하면 Throwable은 Error와 Exception의 부모이기 때문입니다.
  • 🧪 확인 중: checkThat() 함수는 매처를 평가하고 나머지 명령문을 중단하지 않고 불일치를 기록합니다.
  • 🛠️ 보고 : 실패 trace는 수집된 모든 투척물을 고유한 줄 번호와 함께 나열합니다. JUnit 전망.
  • 📌 JUnit 5: Jupiter에서 규칙이 사라졌으므로 assertAll() 또는 AssertJ SoftAssertions가 동일한 역할을 합니다.

JUnit 테스트 실행 중 여러 오류를 수집하는 ErrorCollector 규칙

일반적인 시나리오에서는 테스트 실행 중에 오류를 식별할 때마다 테스트를 중지하고 오류를 수정한 후 테스트를 다시 실행합니다.

그러나 JUnit 약간 다른 접근 방식을 가지고 있습니다. JUnit 오류 수집기를 사용하면 문제가 발견되거나 테스트가 실패한 후에도 테스트 실행을 계속할 수 있습니다. 오류 수집기는 모든 오류 객체를 수집하여 테스트 실행이 완료된 후 한 번만 보고합니다.

오류 수집기를 사용하는 이유는 무엇입니까?

테스트 스크립트를 작성하는 동안 네트워크 오류, 어설션 실패 또는 기타 이유로 코드 실행이 실패하더라도 모든 테스트를 실행하고 싶을 수 있습니다. 이러한 상황에서는 특정 기능을 사용하여 테스트 스크립트 실행을 계속할 수 있습니다. JUnit "오류 수집기"로 알려져 있습니다.

이를 위해, JUnit 를 사용하여 @Rule 주석이 메서드는 오류 수집기 객체를 생성하는 데 사용됩니다. 오류 수집기 객체가 생성되면 해당 메서드를 사용하여 모든 오류를 객체에 쉽게 추가할 수 있습니다. addError(발생 가능한 오류). 아시다시피, 던질 수있는 이것은 최상위 클래스입니다. 예외 오류 수업 Java이런 방식으로 오류를 추가하면 해당 오류가 로그에 기록됩니다. JUnit 검사 결과.

오류 수집기에 모든 오류를 추가하면 모든 오류를 한 번에 확인할 수 있다는 장점이 있습니다. 또한 스크립트 실행 중에 오류가 발생하더라도 테스트 메서드의 실행은 계속 진행됩니다.

주의 사항: 간단한 assert나 try/catch 블록을 사용하는 경우에는 오류 수집기 메서드를 사용할 수 없습니다.

샘플 코드

오류 수집기에 대해 더 자세히 알아보려면 아래 코드 예제를 참조하세요. 이 예제는 오류 수집기 객체를 생성하고 모든 오류를 해당 객체에 추가하는 방법을 보여줍니다. track 문제:

package guru99.junit;		

import org.junit.Rule;		
import org.junit.Test;		
import org.junit.rules.ErrorCollector;		

public class ErrorCollectorExample {				
    @Rule		
    public ErrorCollector collector = new ErrorCollector();							

    @Test		
    public void example() {					
    collector.addError(new Throwable("There is an error in first line"));							
    collector.addError(new Throwable("There is an error in second line"));							
    collector.checkThat(getResults(),			
                not(containsString("here is an error")));			
    // all lines of code will execute and at the end a combined failure will		
    be logged in.		
    }		
}	

참고 : 이것은 예시입니다trac컴파일 가능한 파일이 아닙니다. 마지막 주석이 앞에 // 없이 두 번째 줄로 넘어가고, getResults() 함수와 Hamcrest 매처는 표시되지 않습니다. 실행 가능한 전체 버전은 아래에 있습니다. ErrorCollector를 사용한 예.

@Rule은 무엇인가요? JUnit?

JUnit 테스트 처리에 있어 특별한 방식을 제공합니다. 테스트 케이스 또는 테스트 스위트를 사용하여 @Rule 주석@Rule을 사용하면 테스트의 동작을 쉽게 추가하거나 재정의할 수 있습니다.

제공되는 몇 가지 내장 규칙이 있습니다. JUnit 테스터가 사용할 수 있는 API이며, 사용자 지정 규칙을 작성할 수도 있습니다. 규칙 필드는 public이어야 하고, 정적이 아니어야 하며, TestRule 인터페이스를 구현하는 유형이어야 합니다.

아래 코드 줄은 @Rule 어노테이션을 오류 수집기와 함께 사용하는 방법을 보여줍니다.

@Rule				
public ErrorCollector collector= new ErrorCollector();

JUnit 5년 참고: Jupiter는 규칙을 확장 API로 대체했으므로 org.junit.jupiter에는 @Rule 및 ErrorCollector가 존재하지 않습니다. 가장 유사한 기능은 Assertions.assertAll() 및 AssertJ SoftAssertions입니다. JUnit 여기에 표시된 4번 코드는 여전히 구형 엔진에서 작동합니다. 자세한 내용은 다음을 참조하십시오. JUnit 주석 전체 맵 튜토리얼ping.

ErrorCollector를 사용한 예

오류 수집기를 이해하기 위해 모든 오류를 수집하는 클래스와 규칙을 만들어 보겠습니다. 여기서는 addError(throwable) 메서드를 사용하여 모든 오류를 추가합니다.

아래 코드는 단순히 "오류 수집기 객체"를 생성하는 규칙을 보여줍니다. 이 객체는 모든 오류를 추가하여 최종적으로 문제를 보고하는 데 사용됩니다.

ErrorCollectorExample.java

package guru99.junit;		

import org.junit.Assert;		
import org.junit.Rule;		
import org.junit.Test;		
import org.junit.rules.ErrorCollector;		

public class ErrorCollectorExample {				
    @Rule		
    public ErrorCollector collector = new ErrorCollector();							

    @Test		
    public void example() {					
    collector.addError(new Throwable("There is an error in first line"));							
    collector.addError(new Throwable("There is an error in second line"));							

        System.out.println("Hello");					
        try {			
            Assert.assertTrue("A " == "B");					
        } catch (Throwable t) {					
            collector.addError(t);					
        }		
        System.out.println("World!!!!");					
    }		
}		

TestRunner.java

위의 테스트 클래스를 테스트 러너에 추가하고 실행하여 모든 오류를 수집해 보겠습니다. 아래 코드를 참조하세요.

package guru99.junit;		

import org.junit.runner.JUnitCore;		
import org.junit.runner.Result;		
import org.junit.runner.notification.Failure;		

public class TestRunner {				
			public static void main(String[] args) {									
      Result result = JUnitCore.runClasses(ErrorCollectorExample.class);					
			for (Failure failure : result.getFailures()) {							
         System.out.println(failure.toString());					
      }		
      System.out.println("Result=="+result.wasSuccessful());							
   }		
}      

출력:

실패를 보세요 trace, 즉 trac모든 오류를 한 곳에 모았습니다. JUnit 조회 결과 실행 횟수는 1회로 집계되었지만, 각각 고유한 줄 번호가 있는 두 개의 오류와 한 개의 실패가 보고되었습니다.

Eclipse JUnit 실패 trac단일 실행에서 수집된 Throwable 오류 2개와 AssertionError 1개를 나열합니다.

Benefits of JUnit 오류 수집기

당신은을 사용할 수 있습니다 JUnit 역설 예를 들어 기능 또는 GUI 유효성 검사를 위해:

  1. assertEquals(String message, Object expected, Object actual)는 두 객체가 같은지 비교하는 메서드입니다.
  2. 마찬가지로, AssertTrue(Boolean Condition)은 조건이 참이라고 주장합니다.

어설션을 사용하면 유효성 검사 테스트가 쉬워집니다. 하지만 한 가지 큰 문제는 어설션 하나라도 실패하면 테스트 실행이 중단된다는 것입니다.

테스트 자동화의 성공을 위해서는 테스트 연속성과 복구 처리가 매우 중요하며, 특히 장기적인 테스트 환경에서 더욱 중요합니다. Selenium 각 검사 실패 후 브라우저를 다시 시작하는 것이 비용이 많이 드는 흐름의 경우, 오류 수집기가 이러한 시나리오를 처리하는 가장 좋은 방법입니다.

자주 묻는 질문

addError(Throwable)는 이미 포착했거나 생성한 오류를 기록합니다. checkThat(value, matcher)는 Hamcrest 매처를 평가하고 불일치를 자동으로 기록하므로, 나머지 문장이 계속 실행되도록 허용하면서도 어설션처럼 읽힙니다.

예. 해당 메서드는 실행이 완료됩니다. JUnit 실패를 표시하고 실패 시 수집된 모든 예외를 출력합니다. trac예. 예시 스크린샷은 단일 테스트 메서드에서 두 개의 오류와 한 번의 실패를 보고합니다.

JUnit 테스트 클래스에서 `@Rule` 어노테이션이 있는 공개 인스턴스 필드를 검색하고 각 어노테이션을 모든 테스트 메서드에 적용합니다. 비공개 또는 정적 필드는 무시됩니다. JUnit 테스트를 실행하는 대신 초기화 오류를 발생시킵니다.

아니요. Jupiter 버전에서는 규칙 메커니즘이 제거되었으므로 org.junit.rules.ErrorCollector는 특정 버전에서만 존재합니다. JUnit 4. 그룹화된 어설션을 위해서는 Assertions.assertAll()을 사용하거나, 더 풍부한 매처가 필요한 경우에는 AssertJ SoftAssertions를 추가하십시오.

네, 흔히 사용되는 방식입니다. 여러 필드가 있는 페이지는 한 번에 유효성 검사를 수행할 수 있으며, 첫 번째 불일치에서 바로 중단하는 대신 모든 불일치를 수집하여 각 오류 발견 시 브라우저 세션을 다시 시작하는 것을 방지할 수 있습니다.

둘 다 보고를 지연시키지만, SoftAssert는 테스트 끝에서 명시적으로 assertAll()을 호출해야 하는 반면, ErrorCollector는 메서드가 반환될 때 자동으로 보고합니다. assertAll()을 호출하는 것을 잊으면 문제가 발생할 수 있습니다. TestNG 실패를 조용히 숨긴다.

AI 비서 그룹은 오랜 실패를 겪었습니다. trac근본 원인별로 분류하면 수집된 20개의 오류가 몇 개의 개별적인 결함으로 줄어듭니다. 또한 어떤 검사가 개별 테스트가 아닌 하나의 통합 실행에 포함되어야 하는지도 알려줍니다.

GitHub 부조종사 `@Rule` 필드를 쉽게 생성할 수 있지만, 규칙이 존재하지 않는 Jupiter 테스트 클래스에 해당 필드를 혼합하여 사용하는 경우가 종종 있습니다. 테스트 스위트를 실행하기 전에 임포트가 `org.junit`인지 확인하십시오.

이 게시물을 요약하면 다음과 같습니다.