/*
이 글은 White Ship 님의 '"더 자바, 코드를 테스트하는 다양한 방법" 인프런 강좌를 듣고 정리한 글입니다.
강좌 링크> www.inflearn.com/course/the-java-application-test/dashboard
*/
[ 1 - JUnit 5 환경 ]
A. 세부 모듈로는 Jupiter, Vintage, Junit Platform이 있다.
B. 우리가 쓰는 @Test 어노테이션은 Junit Platform의 지원이 있기 때문이다.
C. Java 8 이상에서 작동하며 대부분의 기능은 Jupiter 안에 있다.
[ 2 - JUnit 5 기본 ]
A. 테스트 클래스와 테스트 함수에 굳이 public 키워드를 붙일 필요가 없다.
B. @BeforeAll, @AfterAll 어노테이션이 붙은 함수는 static void 로 작성해야 한다.
i. 함수 이름은 어떻게 하든 상관이 없다.
C. @Disabled 어노테이션이 붙은 함수는 테스트가 실행되지 않는다.
i. resources/junit-platform.properties 에 있는 Junit 5 설정에서 Junit.conditions.deactivate 값을 설정해 줄 수 있는데, 이 경우에는 Disable과 관련된 어노테이션을 비활성화하여 테스트가 실행되게 할 수도 있다.
[ 3 - JUnit 5 Assertion ]
A. 한 함수 내에서 첫 번째 assert문이 깨지면 다음 assert 문은 실행되지 않는다.
i. 만약 앞에 assert문이 깨지든 말든 모두 수행하고 싶다면 assertAll()로 assert문들을 묶어주어야 한다.
B. assertTimeout(), assertTimeoutPreemptively()를 사용하면 특정 함수가 제한된 시간 내에 끝나는지를 테스트할 수 있다.
i. assertTImeoutPreemptively()는 ThreadLocal 등의 개념과 섞어 쓸 때 Transaction이 지켜지지 않을 여지가 있다. 그래서 안전하게 테스트하려면 시간이 좀 더 걸려도 assertTimeout()을 쓰는 게 낫다.
C. assumeTrue()를 사용하면 이 함수가 통과된 경우에만 다음 코드가 실행된다.
D. @EnabledOnOs, @DisabledOnOs 등 여러 조건을 걸 수 있는 어노테이션들이 있다.
[ 4 - JUnit 5 태깅 ]
A. @Tag로 테스트들을 카테고리별로 나눌 수 있다.
i. 예를 들어 빠른 테스트와 느린 테스트의 구분 등...
B. 프로그래머가 직접 커스텀 태그를 만들어 사용할 수도 있다.
[ 5 - JUnit 5 테스트의 반복 ]
A. @RepeatedTest 어노테이션을 사용하면 테스트를 반복할 수 있다.
B. @ParameterizedTest, @ValueSource 어노테이션으로 테스트의 파라미터를 정의해 줄 수 있다.
i. 여러 인자값을 파라미터로 넘겨줘야 할 경우 @CsvSource 어노테이션을 사용할 수 있다. 이 경우 ArgumentsAggregator를 구현한 클래스와 @AggregateWith 어노테이션을 함께 사용해야 한다.
[ 6 - JUnit 5 테스트 인스턴스 ]
A. Junit 5의 기본 전략은 테스트 함수마다 인스턴스를 생성한다. (테스트 간 의존성을 없애기 위해..)
B. Junit 5 에서는 테스트 클래스마다 인스턴스를 만드는 방식도 가능해졌다.
i. @TestInstance(TestInstance.LifeCycle.PER_CLASS) 어노테이션을 테스트 클래스에 붙인다.
ii. 이 클래스에서는 테스트 함수가 static일 필요가 없어진다. 단, 예외 상황으로 @BeforeAll과 @AfterAll 함수들은 static이어야 한다.
C. 테스트 간 순서는 의존성이 없는 게 좋지만, 특별히 있어야 한다면 테스트 인스턴스의 범위를 클래스로 설정하고 @TestMethodOrder 어노테이션으로 테스트 간 순서를 정할 수 있다.
[ 7 - JUnit 5 설정 ]
A. 테스트 인스턴스의 범위 등 Junit 5와 관련된 설정은 이 파일에서 선언해주면 된다.
[ 8 - JUnit 5의 확장 모델 ]
A. @Extension 어노테이션을 사용한다.
B. 확장 모델을 사용하면 오래 걸리는 테스트만 특정 로깅을 수행하는 동작 등을 구현할 수 있다.
C. 테스트 클래스 내부에서 @RegisterExtension 어노테이션을 붙인 Extension 클래스를 static 변수로 선언하면 어노테이션 없이 테스트 확장 모델을 사용할 수 있다.
[ 9 - Mockito ]
A. Mock이란 진짜 객체와 비슷하게 동작하지만 프로그래머가 직접 그 행동을 관리하는 객체이고, Mockito란 Mock 객체를 쉽게 만들고 관리 및 검증할 수 있는 방법을 제공한다.
B. Unit Test에 관해서는 객체를 하나의 단위로 보는 관점과 행동을 하나의 단위로 보는 관점등 여러 철학이 존재한다.
i. 마틴 파울러가 Unit Test에 대해 설명한 글을 읽어보길 추천한다 (https://martinfowler.com/bliki/UnitTest.html)
C. Mockito 객체를 사용할 땐 직접 만드는 방법과 어노테이션을 사용하는 방법이 있다.
i. 직접 만들 때에는 Mockito.mock(MyClass) 함수를 호출하여 객체를 생성한다.
ii. 어노테이션을 사용할 때에는 테스트 함수에 @Mock, 테스트 클래스에 @EtendWith(MockitoExtension.class) 어노테이션을 붙여준다. 특정 테스트 함수에만 Mock 객체를 사용하고 싶으면 파라미터로 @Mock 어노테이션이 딸린 Mock 객체를 넣어주면 된다.
D. Stubbing 이란 Mock 객체의 행동을 조작하는 행위를 가리킨다.
i. when(… 특정 행동 …).thenReturn(… 원하는 리턴 값 …) 의 방식으로 Stubbing한다.
ii. when().thenReturn().thenReturn().thenThrow().thenReturn()… 이런 식으로 메소드 체이닝을 하면 각 thenReturn()마다 첫번째, 두번째, 세번째 호출의 리턴값 또는 Exception 값을 정해줄 수 있다.
E. Mock 객체의 특정 함수가 몇 번 호출되었는지 등을 확인하기 위해서는 verify() 함수를 사용할 수 있다.
i. 만약 Mock 객체의 행동이 특정 순서로 호출되었는지 확인하고 싶은 경우, Mock 객체의 InOrder 객체를 얻어와서 verify()를 같은 호출 순서로 실행하면 된다.
F. BDD는 어플리케이션이 어떻게 “행동”해야 되는지에 대한 공통된 이해를 구성하는 방법이며, given / when / then 형식을 가진다.
G. Mockito에서도 when() 대신 given()을, verify() 대신 then()을 사용하도록 배려함으로써 BDD를 지원한다.
[ 10 - 성능 이슈 테스트 ]
A. JMeter는 성능 측정 및 부하 테스트 기능을 제공해준다.
B. 특정 시간내에 다수의 http request를 보내는 등 어플리케이션의 성능을 측정한다.
[ 11 - 운영 이슈 테스트 (Chaos Monkey) ]
A. 운영 환경에서 간헐적으로 발생하여 미리 알기 힘들지만 일단 발생하면 큰 여파를 끼치는 버그들을 미리 알아내기 위해 운영 이슈 테스트를 수행한다.
B. 카오스 엔지니어링 책도 읽어보면 좋다. (http://channy.creation.net/blog/1173)
C. 공격 대상(Watcher)와 공격 유형(Assaults)로 구성된다.
D. Chaos Mokey는 Spring Boot 또한 지원해준다.
[ 12 - 아키텍처 테스트 ]
A. 어플리케이션이 전체적으로 프로그래머가 의도한 설계대로 작성되었는지 테스트할 수 있는 방법이다.
B. ArchUnit
i. 어플리케이션의 아키텍처를 테스트할 수 있는 오픈 소스 라이브러리이다.
ii. 패키지, 클래스, 레이어, 슬라이스 간의 의존성을 확인할 수 있는 기능을 제공한다.
iii. FreezingArchRule 속성은 기존에 이미 깨져버린 아키텍처는 warning을 무시하고 추가적으로 생기는 깨짐들만 warning을 띄우도록 하는 속성이다. 이미 망가져버린 아키텍처가 다수 존재할 때 유용하게 사용할 수 있다.
[ 13 - 기타 테스트 툴 ]
A. 브라우저 별 이슈를 테스트해보기 위해 Selenium WebDriver 라이브러리를 사용할 수 있다.
i. Selenium WebDriver는 웹 브라우저 기반 자동화된 테스트 작성에 사용하는 툴이다.
B. 본격적으로 BDD 시나리오를 따라 테스트하고 싶다면 Cucumber 도 좋은 선택이 될 수 있다.