TDD 연습
느낀점과 중요한 점을 몇가지 알아 보자.
- 테스트를 먼저 정의하라
- 어떤 것을 테스트할지 먼저 테스트를 만들고 나서 실제 작동 코드를 작성하여 테스트 통과 시키기
- 어떻게든 테스트가 통과하면 된다
- 처음부터 너무 완벽하게 짤 필요가 없음. 테스트를 통과시키는 코드를 어떻게든 짜면 되고 다음의 여러개 테스트를 만들며 코드를 점점 완성해 나가면 된다.
- 테스트가 통과한 뒤 항상 리펙토링을 하라
- 테스트 검증을 통과시킨 뒤에는 항상 리펙토링을 하라.
밑의 코드는 최범균님의 유튜브에 올라온 TDD 연습과 관련된 코드이고, note라는 부분에 강조를 위해 {} 를 치는 코드이다. 이를 위해 하나하나 검증식을 넣어가며 코드를 발전시키고 있는 부분이다.
TDD의 좋은 점은 빠르게 기능을 확인 할 수 있다는 점이고, 이를 리펙토링을 통해 점차 가다듬어 가며 코드를 발전 시킬 수 있다는 것을 확인하였다.
테스트에서 Mockito, 테스트용 구현
-
당장 필요하지 않는 구현에 대하여 가짜 구현체를 사용할 수 있다. 여기서 가장 유명한 프레임워크가 바로 Mockito.
-
테스트할때, DB와 관련해서 로직이 들어가는데, Mock 객체를 사용하면, 구현이 어려워 질 수 있다. 이럴때는 메모리 구현체를 사용하던 해서 테스트용으로 하나 레포지토리를 구현하는게 더 낫다고 한다.
-> 당장에는 무언가 더 만들어야 되서 힘들지만 DB에서 Mock을 이용하는 것 보다는 이런 메모리 레포지토리 하나 구현을 하는게 더 편리하게 테스트가 가능하게 도와준다고 한다.
결국 현재 테스트를 하는데서 당장 필요하지 않은 클래스에 대하여 대역을 만들어 줄 수 있는 것이 Mockito framework이며 이러한 것을 쓰는 이유는 TDD에서는 모든것을 구현해 놓고 테스트 하지 않기 때문에(실제 구현되지 않은 클래스가 있을 수 도 있음), 임시로 가짜 객체를 만들어 넣어서 테스트를 하는 것이다.
최범균님의 유튜브 영상 TDD 대역 연습을 보며 학습.
PayMethodRegReqValidator mockValidator = mock(PayMethodRegReqValidator.class);
UserChecker mockUserChecker = mock(UserChecker.class);
CardValidityChecker mockCardChecker = mock(CardValidityChecker.class);
private PayMethodRegister pr;
private PayMethodRepository payMethodRepository = new MemoryPayMethodRepository();
@BeforeEach
void setUp() {
pr = new PayMethodRegister(mockValidator,
mockUserChecker,
mockCardChecker,
payMethodRepository);
}현재 결제 등록에 클래스인 PayMethodRegister에 대해 테스트를 하는데, validator 클래스들의 구현이 전부 되어 있지 않는 것이다. 이때 mock을 이용해 사용.
또한 결제 정보를저장하는 Repository도 따로 구현되어 있지 않은 상황. 이때는 Mock이 아닌 MemoryRepository를 구현하여 사용. -> 리포지토리는 Mock보단 메모리구현을 하는것이 편하다.
TDD를 하며 구현해 갈때 모의 객체, 가짜구현, stub 등의 대역을 사용하여 별도의 타입으로 분리하는 과정 자체가 자연스럽게 역할을 분리하는 과정이 된다. 설계 과정에 도움이 됨.
TDD를 사용하며, 역할 분리를 할때 이런 것이 자연스럽게이루어 지는 것도 있다.
실제 프로젝트에서 테스트 코드를 짜며 느낀 점
빠른 테스트를 위해 테스트의 크기를 적절하게 조절할 필요가 있다.
@SpringBootTest같은 애노테이션을 사용해 스프링 프로젝트의 환경을 통째로 올릴 필요가 없다.
-
Slice test, Unit Test 같이 더 작게 테스트하여 디버깅을 하기 쉽게 하고, 테스트의 목적인 기능의 검증을 더 잘 할 수 있게 될 것이다.
(한번 테스트를 돌리는데 엄청 오래걸리면 자주 실행하기 부담스러워짐 -> 한번에 많은 코드를 짜고 테스트를 하게됨. -> 오류 수정 파악이 힘들어지고 오래 걸림) -
TDD의 장점중 하나가 계속해서 테스트를 돌려가며, 기능이 예상한 대로 돌아가느냐인데, Spring Project를 통째로 올려서 테스트하면 생각보다 테스트 하나 돌리는데 시간이 오래 걸리게 된다.(필요없는 의존성 주입을 너무 많이 받는다). Unit 테스트를 통해 테스트가 빠르게 이루어지도록 하자. 왜 TDD에서 Unit test가 강력한 파트너인지 느끼게 되었다.
