다음 내용은 토비와 토비의 봄을 읽고 나온 부분을 개인적으로 공부하여 정리한 것입니다.
하나. 공용 액세스를 위한 JUnit 및 수정자 개발
JUnit은 Java 세계에서 사용되는 테스트 프레임워크입니다.
오늘날 우리가 알고 있는 JUnit 4와 5는 각각 2006년과 2016년에 출시되었습니다.
이전 버전도 있지만 이번에는 JUnit3을 살펴보겠습니다.
- Junit3: 2007년 마지막 릴리스
- Junit4: 2006년 첫 출시
- Junit5: 2016년 첫 출시
(Junit3의 규칙 및 규칙)
JUnit3으로 테스트를 실행하기 위한 몇 가지 규칙과 규칙이 있으며 기본적으로 다음과 같습니다.
- 테스트 클래스는 TestCase 클래스에서 상속해야 합니다.
- 테스트 방법은 테스트로 시작해야 합니다.
- 테스트 클래스와 메서드는 공개되어야 합니다.
JUni3 기반 테스트를 작성하면 실제로 이렇게 작성됩니다.
import junit.framework.TestCase;
public class CalculatorTest extends TestCase {
public void testAdd() {
// given
Calculator calculator = new Calculator();
// when
int result = calculator.add(1, 2);
// then
assertEquals(result, 3);
}
}
TestCase 클래스를 상속하지 않으면 JUnit3은 해당 클래스를 테스트 클래스로 인식하지 않습니다.
테스트 방법이 테스트로 시작하지 않더라도 테스트 방법으로 인식되지 않습니다.
그리고 테스트 클래스와 테스트 메서드의 가시성은 공개되어야 하며 JUnit 개발자가 공개한 이유가 있습니다.
기본적으로 JUnit은 Reflection API를 통해 테스트 클래스의 메서드를 호출합니다.
리플렉션을 사용하는 이유는 Pluggable Selector 패턴을 사용했기 때문입니다.
자세히 살펴보기 위해 위의 테스트를 다음과 같이 수정해 보겠습니다.
생성자 호출 수를 계산하기 위해 생성자에 print 문을 추가하고 3개의 동일한 테스트를 실행했습니다.
import junit.framework.TestCase;
public class CalculatorTest extends TestCase {
public CalculatorTest() {
System.out.println("CalculatorTest created");
}
public void testAdd() {
// given
Calculator calculator = new Calculator();
// when
int result = calculator.add(1, 2);
// then
assertEquals(result, 3);
}
public void testAdd2() {
// given
Calculator calculator = new Calculator();
// when
int result = calculator.add(1, 2);
// then
assertEquals(result, 3);
}
public void testAdd3() {
// given
Calculator calculator = new Calculator();
// when
int result = calculator.add(1, 2);
// then
assertEquals(result, 3);
}
}
위의 테스트를 실행하면 호출 결과는 다음과 같습니다.
테스트 클래스의 개체는 세 번 생성됩니다.
CalculatorTest created
CalculatorTest created
CalculatorTest created
이것은 JUnit 때문입니다.
독립적으로 테스트됨 보장따라서 각 테스트마다 새로운 테스트 클래스 개체가 생성됩니다.
그러나 이러한 테스트의 독립성을 보장하려고 하면 어떤 테스트 클래스 개체에서 어떤 테스트 메서드를 호출해야 하는지 선택하기 어렵기 때문에 문제가 발생했습니다.
따라서 JUnit은 특정 메소드를 호출하기 위해 특정 테스트 클래스 객체를 동적으로 선택하는 pluggable selector 패턴을 적용해야 했고, 테스트로 시작하는 메소드만 리플렉션을 사용한 테스트로 인식했습니다.
그런데 이 JUnit이 처음 빌드되었을 때 사용된 JDK 버전은 1.1이었고, JDK 1.1은 리플렉션에서 공용 메서드에 대한 액세스만 허용합니다.
했다.
따라서 과거에는 JUnit의 모든 테스트 메서드가 public이어야 했고 메서드 이름은 test로 시작해야 했습니다.
참고로 테스트 케이스는 역사적으로 Test라는 인터페이스를 구현하여 만들어야 했기 때문에 테스트 클래스당 하나의 테스트 메서드만 작성할 수 있었던 시절이 있었습니다.
( Junit4)의 규칙 및 규칙
JUnit4에서 테스트를 실행하기 위한 몇 가지 규칙과 규칙이 있으며 기본적으로 다음과 같습니다.
- 테스트 클래스와 메서드는 공개되어야 합니다.
- 테스트 메서드는 @Test 주석으로 주석을 달아야 합니다.
JUni4 기반으로 테스트를 작성하면 실제로 이렇게 작성됩니다.
public class CalculatorTest {
@Test
public void addTest() {
// given
Calculator calculator = new Calculator();
// when
int result = calculator.add(1, 2);
// then
assertEquals(result, 3);
}
}
JDK 1.5 노트이것이 들어왔을 때 JUnit에 큰 변화가 일어났고, @Test 주석 사용오전. 마찬가지로 JUnit4도 각각의 테스트 클래스 객체를 생성하여 독립적인 테스팅을 보장하며, 테스트 메소드 선택 시 @Test가 있는 메소드만 테스트로 인식하였다.
이 부분은 테스트 방법이 테스트로 시작하지 않아도 되도록 개선되었습니다.
그럼에도 불구하고 테스트 클래스와 메서드는 공개되어야 합니다.
JDK 1.2부터는 모든 액세스 수준이 Reflection API를 통해 허용됩니다.
그래도 JUnit4까지는 공개 테스트 클래스와 메서드를 연결해야 하지만 JUnit 개발자는 이를 포기합니다.
전통을 살리기 위해이였다고 한다
( Junit5 규칙 및 규칙)
JUnit5에서 테스트를 실행하려면 한 가지만 명심하면 됩니다.
- 테스트 메서드는 @Test 주석으로 주석을 달아야 합니다.
JUni5 기반 테스트를 작성하면 실제로 이렇게 작성됩니다.
class CalculatorTest {
@Test
void addTest() {
// given
Calculator calculator = new Calculator();
// when
int result = calculator.add(1, 2);
// then
assertEquals(result, 3);
}
}
JUnit 5부터 게시 전통이 완화되었습니다.
따라서 private을 제외한 모든 액세스 수정자를 사용할 수 있으며 일반적으로 표준 접근자를 통한 간단한 입력할 수 있습니다.
그 외에 독립적인 테스트를 위한 새로운 테스트 클래스 개체를 생성하는 것은 동일합니다.
실제로 JUnit은 테스트 성능을 최적화하기 위해 하나의 테스트 클래스 객체만 사용하는 방법을 제공합니다.
@TestInstance 관련당신은 그것을 검색해야합니다.
실제로 기존 JUnit4와 달리 JUnit5는 다음과 같은 많은 변화를 겪었습니다.
B. 실제 구현 모듈에서 인터페이스 모듈의 분리. 나중에 시간이 맞을 때 이에 대해 자세히 논의하겠습니다.
다음 내용은 토비와 토비의 봄을 읽고 나온 부분을 개인적으로 공부하여 정리한 것입니다.
아래 관련 정보 지름길거기도 있으니 한번 가보시면 좋을 것 같습니다.