🧾 @Nested

JUnit 5에서 도입된 기능으로, 테스트 클래스 내에 중첩된(inner) 테스트 클래스를 나타내기 위해 사용된다. @Nested를 사용하면 단일 테스트 클래스 내에서 테스트 클래스를 좀 더 구조적으로 나눌 수 있으며, 각 내부 테스트 클래스는 특정 상태나 동작에 관련된 테스트를 그룹화할 수 있다.

특징

중첩된 테스트 클래스
- @Nested 어노테이션은 특정 테스트 클래스 내에 논리적인 하위 테스트 클래스를 정의
상태 공유
- 중첩된 테스트 클래스는 바깥쪽 테스트 클래스의 private 필드와 메서드에 접근할 수 있어서, 상태를 공유하거나 특정 상태에서의 동작을 테스트하기 용이
구조적인 테스트
- @Nested를 사용하면 테스트 클래스를 좀 더 구조적으로 구성할 수 있습니다. 예를 들어, 특정 메서드에 대한 성공, 실패, 예외 상황 등을 각각 다른 중첩 클래스로 나눌 수 있음
읽기 쉬운 테스트 코드
- 중첩된 테스트 클래스를 사용하면 테스트 코드를 좀 더 읽기 쉽게 만들 수 있습니다. 각각의 중첩된 클래스는 특정 책임이나 상황에 집중할 수 있음

JUnit 스터디

1장

- JUnit 1장
- JUnit 2장

📝 1장

🧾 @Nested란?

📝 2장

[[🧾 @Nested란?|🧾 @N

📝 1장

[🧾 @test란?|🧾 ]

]]

맴버

구간 1

이 글은 책을 읽은 후 책 본문을 인용하거나 글쓴이의 생각을 가미하여 작성 한 글입니다. 따라서 책의 대한 내용을 올바르게 이해하는 것은, 직접 책을 읽고 이해하는 것이 가장 베스트입니다.

JUnit의 필요성

개발자가 개발을 하다보면 모든 코드는 테스트를 하게 되어있다. 어떠한 컴포넌트가 실제 구동환경에서도 제대로 동작하는지는 충분한 테스트를 거치지 않으면 결국 증명할 방법이 없기 때문이다. 보통 테스트를 하면 어떻게 하는지 생각해보면, 직접 코드를 실행하고 컴파일 레벨에서 에러가 발생하지 않는다면 테스트 케이스를 통해 직접 하나 하나 액션을 취하면서 동작이 잘 하는지 확인을 하고 에러가 발생한다면 프로그램을 멈춘 후 에러가 발생한 코드를 찾아가 고쳐가는 방식을 한다. 자바의 환경에서라면 익셉션을 통해 에러가 유발 될 부분에 대해 프로그램이 멈추지 않도록 예외처리를 할 것이지만 결국 고쳐야 하는건 매한가지다. 이러한 테스트를 하다보면 결국 테스트 케이스 기반의 데이터 등록, 에러확인, 수정을 반복적으로 할 것이다. 데이터의 이동을 하나하나 확인하면서 검증하는 개발자는 이 행위를 좋아하겠지만 검증 과정에 있어 시간이 개발하는만큼 들 수 있으므로 좋아하지 않는 개발자도 분명히 있다. JUint은 이 반복적인 테스트 행위를 간편하게 행하도록 해주는 테스트 프레임워크 이다. 이 JUnit은 앞서 얘기한 일련의 테스트가 자동화되어 소프트웨어 개발 프로세스에 필수요소로 들어가면 좋겠다 생각한 '에릭 감마'와 '켄트 백' 두 개발자가 만든 SUnit이 시발점이다.

JUnit의 설계 목표

JUnit의 설계 목표는 다음과 같은 3가지이다.

- 유용한 테스트를 작성하는 데 보탬이 되어야 한다.

- 시간이 지나도 가치가 변치 않는 테스트를 작성하는 데 보탬이 되어야 한다.

- 코드 재사용을 통해 테스트 작성 비용을 낮추는 데 보탬이 되어야 한다.

단위테스트의 정의

단위테스트는 명확한 작업 단위의 동작을 검사한다. 명확한 작업 단위는 일반적으로 하나의 메서드를 간주한다. 통합테스트나 인수테스트는 다양한 컴포넌트 또는 외부환경 사이의 상호작용을 검증한다. 즉 단위테스트는 어떤 다른 작업에도 직접적으로 영향을 받지 않는 작은 단위의 테스트를 일컫는다.

단위테스트의 규칙

- 단위 테스트는 다른 모든 단위 테스트들과 독립적으로 실행되어야 한다.

- 프레임워크는 테스트 각각의 오류를 식별하고 보고해야 한다.

- 어떤 테스트를 실행할지 선택하기 쉬워야 한다.

구간 2

이 글은 책을 읽은 후 책 본문을 인용하거나 글쓴이의 생각을 가미하여 작성 한 글입니다. 따라서 책의 대한 내용을 올바르게 이해하는 것은, 직접 책을 읽고 이해하는 것이 가장 베스트입니다.

테스트 클래스

- public class 여야 하고, 파라미터를 받지 않는 생성자를 제공해야 한다.

- 테스트 메서드는 @Test 애노테이션이 있어야 하고, public이고, 파라미터도 받아서는 안된다. 반환형은 void여야 한다.

- JUnit은 각 @Test 메서드를 호출할 때마다 테스트 클래스의 인스턴스를 새로 생성하며 모든 테스트 메서드는 각기 다 른 테스트 클래스 인스턴스에서 실행되므로 인스턴스 변수는 공유될 수 없다.

- 테스트 검증에는 Assert 클래스에 정의된 assert 메서드를 사용한다.

- assert 메서드 중 파라미터 2개를 받는 요소들은 항상 같은 패턴(기대결과값,테스트값)을 따른다.

assert method	목적
assertArrayEquals("message", A, B)	배열 A와 B가 일치함을 확인
assertEquals("message", A, B)	객체 A와 B가 일치함을 확인. B를 파라미터로 A의 메서드를 호출(A.equals(B))
assertSame("message", A, B)	객체 A와 B가 같은 객체임을 확인한다. Equals는 값을 확인 했다면, Same은 물리적으로 동일 객체인지 비교한다.(메모리 주소 비교)
assertTrue( "message", A)	조건 A가 참(TRUE)임을 확인
assertNotNull( "message", A)	객체 A가 NULL이 아님을 확인

테스트 스위트

- 테스트 스위트는 특수한 형태의 테스트 러너로 여러개의 테스트 클래스를 동시에 실행할때 쓰이는 객체, 일종의 테스트 집합이며 별도로 테스트 스위트가 정의되지 않았다면 JUnit이 테스트 클래스 내 모든 테스트들을 포함하는 스위트를 자동으로 만들어준다.

테스트 러너

- 테스트 스위트를 실행하는 일종의 엔진

파라미터화(parameterized)는 버전 4, 5가 차이가 있으므로 내용 생략.

[##Image|kage@d4NgW8/btsBT0cU6No/CjL2w7RKejik2RBPiqSrGK/img.png|CDM|1.3|{"originWidth":778,"originHeight":1161,"style":"alignCenter"}##][##Image|kage@3Wvps/btsBXQmxtWm/PPM8NTlIiKcYAvgSCaPKDK/img.png|CDM|1.3|{"originWidth":793,"originHeight":816,"style":"alignCenter"}##][##Image|kage@bThn1w/btsBVGSglNP/ISCFKVqKBFksfrtVfkfn91/img.png|CDM|1.3|{"originWidth":896,"originHeight":1057,"style":"alignCenter","caption":"JUnit5 ParameterizedTest 중, MethodSource 적용 예시, MOCK MVC대신, Controller에서의 param 임의 생성"}##]

Provide feedback

Saved searches

Use saved searches to filter your results more quickly