픽플 프로젝트를 진행하며 테스트코드를 짜야지, 짜야지 하다가 최종 발표 일정에 허덕이면서 테스트코드까지 작성하기는 너무 무리일 것 같아서 결국 최종발표가 끝나고서야 작성하게 되었다.
테스트코드를 어떻게 작성해야 하는지에 대한 개념이 너무 없었기 때문에 오늘부터 테스트케이스를 뽑고, 기초적인 내용 등을 정리하겠다.
JUnit을 활용한 테스트코드 작성
우선 전공 교과목 교수님이 강의해주시는 내용을 듣고 강의를 정리해본 후에, 추가적으로 더 필요한 내용을 추가해나간다.
1. 라이브러리 추가
2. 테스트코드 작성에 필요한 기본 어노테이션
| 어노테이션 | 설명 |
|---|---|
| @Test | 단위 테스트를 하기 위한 어노테이션이다. |
| @BeforeAll, @AfterAll | @Test가 붙은 모든 메소드들의 앞뒤(Before, After)로 해당 메소드를 실행시킨다. |
| @BeforeEach, @AfterEach | |
| @DisplayName, @DiaplayNameGeneration | @DisplayName("테스트명") 이라고 붙여주면, 테스트의 이름이 "테스트명"으로 명시된다. 굳이 하지 않아도 된다. @DisplayNameGeneration(DisplayNameGenerator.ReplaceUnderscores.class) : 언더바(_)를 공백( )으로 바꾸어준다. |
Tip
- 메소드들을 굳이 public으로 선언하지 않아도 된다.
- 목록에서 ~All이 붙은 어노테이션과, ~Each가 붙은 어노테이션은 사용 시 차이가 있다.
~All이 붙은 어노테이션에는 static키워드가 붙고, return값이 존재하면 안된다.
~Each가 붙은 어노테이션에는 staic키워드를 빼줘야 한다.
static이 붙는 케이스는 test를 위한 instance가 매번 생성되어서는 안되고, 하나의 인스턴스(마치 싱글톤처럼)로 공유되어야할 때 사용한다.
3. BDD, TDD
Behavior-Driven Development의 약자로, 테스트케이스 자체가 요구 사양이 되도록 하는 개발방법이다(TDD와 비슷하지만 보완적이고 다른 개념).
BDD의 기본 패턴
개발자가 아닌 다른 사람이 봐도 이해할 수 있을 정도의 테스트케이스를 작성하는것이 목적이다. 하나의 시나리오는 Given-When-Then구조를 가지는 것을 기본패턴으로 권장하고 있다.
- Given : 시나리오 진행에 필요한 값을 설정. 즉 인스턴스를 생성(Application Context)하고,
- When : 시나리오 진행 시 필요한 조건 명시. 작성한 Class나 API들을 실행했을 때,
- Then : 시나리오를 완료했을 때 보장해야 하는 결과를 명시. 원하는 결과가 나오는지 검증한다(Assert).
4. Test의 실행 순서
테스트의 실행 순서는 메소드를 작성한 순서대로가 아니다. 즉, 작성한 메소드 순서대로 실행되는것이 아니다.
이는 단위테스트 간의 dependency를 없애기 위한 방편이다.
하지만 순서가 필요한 테스트의 경우, 테스트케이스의 순서를 명시적으로 정해주는 방법이 있다(따로 찾아볼 것 !)
5. Assert
Assert~ 메소드는 Exception이 발생할 경우 모든 Test가 멈춘다. 따라서 먼저 수행되는 테스트가 성공하지 못하면 다음 테스트 코드도 검증이 불가능하다.
이를 방지하기 위해 assertAll()을 사용한다. assertAll(테스트케이스, 테스트케이스...) 파라미터 갯에 관계없이 사용할 수 있다.(Excutable)
AssertEquals를 사용하는 것은 가독성이 떨어진다. 그래서 AssertThat을 사용해 가독성을 높일 수 있다. (Hamcrest, AssertJ등의 라이브러리로 사용가능하다).
- 라이브러리
- Hamcrest : Matcher를 사용할 때 정확한 사용방법을 알고있어야 사용가능하다는 어려움이 있다.
- AssertJ : Hamcrest의 어려움으로 인해 더 직관적인 표현법으로 사용할 수 있다.
- Assertions.assertThat({matcher type}) : matcher type이 string이냐, integer이냐, 새로운 타입의 자료형이냐에 따라 mapping되는 메소드들이 달라진다)
6. Mocking
테스트를 할 때 진짜 객체를 만들어서 진짜 DB에 삽입되게 한다면 데이터에 대한 신뢰도도 떨어지고, 나중에 실제로 서비스를 할 때 테스트했던 정보들을 일일이 손봐야할 것이다. 그래서 테스트를 위해 하나의 가짜 객체를 만들어 사용한다. 가짜 객체를 사용한다면 테스트 데이터와 실제 데이터에 경계가 생기므로 단위테스트 하기에 적합하다. 테스트를 할때는 Mocking을 하는 것이 좋다.
