본문 바로가기

소개

 

 

최근에 테스트 주도 개발 시작하기라는 책을 구매했다. 책을 구매하기전에 아래와 같은 이유때문에 TDD관련 강의나 책을 찾아보고 있었는데 테스트 주도 개발 시작하기 라는 책이 딱 맞다고 생각해서 구매했다.

 

1. 회사에서 자바 프로젝트 개발시 표준 테스트 프레임워크로 Junit5를 사용하는데 Junit5를 기준으로 테스트 코드가 작성되어 있으면 좋겠다

 

2.  소프트웨어 테스트에대한 기초적인 용어나 테스트의 범위에 대한 설명과 테스트 코드를 잘 작성하는 방법등이 포함되어 있는 강의나 책이 있으면 좋겠다는 생각을 가지고 있었다.

 

 

 

테스트 주도 개발 시작하기

TDD(Test-Driven Development)는 테스트부터 시작한다. 구현을 먼저 하고 나중에 테스트하는 것이 아니라 먼저 테스트를 하고 그다음에 구현한다. 구현 코드가 없는데 어떻게 테스트할 수 있을까? 여기��

www.yes24.com

 

 

 

정리

 

TDD에 관해서

 

책 전반적으로 실제 TDD방식으로 개발을 하도록 구성되어 있다. 테스트 코드를 먼저 적고 개발을 한다는게 솔직히 어떤 느낌인지 이해가 되지 않았는데 이 책의 예제 코드를 따라적으면서 TDD라는게 어떤 철학을 가지고 있는지 알게되었다.

 

TDD는 `테스트코드 작성` -> `통과 시킬만큼 구현` -> `리팩토링`이라는 짧은흐름을 반복해서 개발하는 과정이다. TDD의 핵심은 테스트를 하고 그 다음에 코드를 구현한다는 것이다. 테스트 코드를 먼저 작성하면서 얻을 수 있는 장점은 뭘까? 테스트 코드를 작성하는 과정에서 클래스 이름, 메서드 이름, 파라미터 개수, 리턴 타입등을 고려하는데 결국 이런 고민이 실제 코드에 반영되면서 더 좋은 코드를 만들어낸다.

 


대역

외부와 의존하는 객체는 테스트하기 어렵다. 외부 네트워크와 단절되는 경우에는 테스트 자체가 불가능하고 일정시간이 초과되는 경우에는 timeout이 발생한다와 같은 테스트를 진행하고 싶은데 외부 API는 이런 상황을 제공하지 못한다면 테스트를 하기가 상당히 어려워진다. 이럴때는 `대역`을 사용하자.

 

대역은 말 그대로 실제 외부의존을 대역하는 객체를 만든다는것을 의미한다. 대역의 종류는 stub,fake,spy,mock이 있다.

 

stub 테스트에 맞게 단순히 원하는 동작을 수행
fake 실제 동작하는 구현을 제공(db대신 메모리에 값을 올리는 케이스??)
spy 호출된 내용을 기록
mock 기대한 대로 상호작용하는지 검증(stub/spy 역할을 수행)

 

 

테스트 범위

 

기능테스트/E2E테스트

 

기능테스트는 사용자 입장에서 시스템이 제공하는 기능이 올바르게 동작하는지 확인하는 테스트이다. 사용자가 직접 웹브라우저나 모바일에서부터 시작해서 DB/외부서버에 이르기까지 모든 구성요소를 하나로 엮어서 진행하기 때문에 E2E테스트로 볼 수 있다.

 

통합테스트

시스템의 각 구성요소가 올바르게 연동되는지 확인하는 테스트이다. 소프트웨어의 코드를 직접테스트한다.

 

단위테스트

개별코드나 컴포넌트가 기대한대로 동작하는지 확인하는 테스트이다. 일부 대상은 모의 객체를 이용해서 대역으로 대체한다.

 

 

 

통합테스트 vs 단위테스트

 

  아래 글에도 포스팅한 적이 있는데 통합테스트는 DB/캐시 서버와 같은 연동대상을 구성해야한다. 단위 테스트보다 준비해야할게 많고 실행 시간도 길기때문에 단위 테스트 코드가 더 많이 작성되게 된다. 하지만 통합테스트가 필요없는것은 아니다. 결국 각 컴포넌트들끼리 올바르게 연동되는 것을 확인해야 성공적인 테스트이자 소프트웨어가 되기때문이다.

 

 

 

컨트롤러 테스트 @WebMvcTest vs @SpringBootTest

Spring 에서 Test 하는 방법 스프링 프레임워크를 테스트 할때 스프링의 `ApplicationContext` 전체를 불러와서 테스트 하는 방법과 특정 레이어만 불러와서 테스트하는 방법이 있다. 전체 테스트는 프로

syundev.tistory.com

 

 

테스트 코드의 유지보수

 

테스트코드도 결국 코드이기때문에 유지보수의 대상이된다. 따라서, 테스트 코드를 이상하게 작성하면 유지보수가 어려워지고 결국 테스트 코드를 주석처리하거나 테스트를 수행하지 않고 배포하는 현상이 발생하게 된다. 책에서 최범균님이 제안한 테스트 코드 작성방법을 모두 읽어보면 결국 비즈니스 로직을 구현할때랑 비슷한것 같다. 한개의 메서드는 한개의 일만 해야한다라는 말이 있는것처럼 `하나의 테스트는 한개만 검증`해야한다고 제안하고 있다. 자세한 내용들은 책에 자세히 설명되어 있다.

 

 

결론

 

TDD를 도전해보려는 입장에서 도움이 많이 되었다. 책을 한번 읽었는데 2번,3번 반복해서 읽고 코드를 따라 적으면서 TDD 개발방법론을 머리가 아닌 몸이 기억하도록 해야겠다. 

 

'개발서적' 카테고리의 다른 글

빅데이터 세상으로 떠나는 간결한 안내서 NoSQL  (0) 2020.08.15

댓글