이전 포스트
TDD - 테스트 코드 작성 순서
이전 포스트 https://hou27.tistory.com/entry/TDD-TDD%EB%9E%80 TDD - TDD(Test-Driven Development)란? TDD를 프로젝트에 적용해보고 싶다는 생각만 항상 했었는데, GDSC에서 스터디를 TDD로 진행하게 되어 이번 기회에 제
hou27.tistory.com
실습 환경
- Java 17
- Spring Boot 3.0.1
- wsl 2
기능 명세
어떤 형태로든 사용자에게 제공할 기능을 구현하려면 입력과 결과가 필요하다.
기능을 실행하는데 필요한 값이 입력이고,
return 값, exception 또는 데이터의 변경 등이 결과라고 할 수 있다.
위 그림은 회원 가입 기능의 입력과 결과를 정리한 예시이다.
상황에 따라 다른 결과를 가지며, 동일한 ID가 이미 존재할 경우 exception을 발생한다.
설계는 기능 명세로부터 시작한다.
스토리보드 등 다양한 형태로 요구사항 문서를 이용해 기능 명세를 구체화하고,
구체화 과정에서 입력과 결과를 도출하고 코드에 반영한다. 이는 곧 기능에 대한 설계 과정과 연결된다.
설계 과정을 지원하는 TDD
TDD는 테스트를 만드는 것에서 시작한다.
- 테스트할 기능을 실행
- 실행 결과를 검증
테스트 코드를 만들기 위해선 위 2가지를 할 수 있어야 한다.
테스트할 기능을 실행하기 위해선
테스트 대상이 될 클래스명을 고민하고, 메서드명, 파라미터를 고민하는 등의 과정을 먼저 거친다.
그 후 기능이 제대로 동작하는지 확인하기 위해 실행 결과를 검증하는 과정을 거쳐야 한다.
정리하자면
클래스명, 메서드명, 메서드 파라미터, 실행 결과를 고민하며 테스트 코드를 작성하며
이 과정을 곧 설계 과정이라고 할 수 있다.
필요한 만큼 설계하기
TDD를 할 땐 테스트를 통과할 만큼만 코드를 작성해야한다.
필요한 것을 예측해서 추가로 미리 코드를 작성하면 안된다.
예측을 통해 미리 작성함으로써 설계를 유연하게 만들지 않고,
실제 테스트 사례를 추가하고 통과하는 과정에서 필요한 만큼 설계를 변경하도록 한다.
테스트를 통과할 만큼만 코드를 작성하게 되면,
현 시점에서 필요한 설계만 코드에 반영할 수 있게 되고 복잡해지는 것을 방지할 수 있다.
미리 앞서서 코드를 작성하지 않음으로써 예상치 못한 변수를 최대한 차단하고 불필요한 구성 요소를 덜어낼 수 있다.
기능 명세 구체화
보통 기획자가 작성한 스토리보드 또는 와이어프레임 등과 같은 형태로 전달받은
요구사항 문서에서 기능의 입력과 결과를 도출하고, 다양한 테스트 사례를 생각해내야 한다.
대부분 개발자의 눈에는 그 과정에서 입력과 결과를 도출하기 애매한 부분이 보이기 마련이고,
이럴 때 기획자나 담당자와의 대화를 통해 구체적으로 정리하는 과정이 필요하다.
모호한 상황은 바로 구체적 예로 바꿔서 테스트 코드에 반영해준다.
테스트 코드는 예를 이용한 구체적인 명세가 되는 것이다.
한번에 모든 것이 명확해질 순 없으므로
테스트 코드를 추가해 가면서 기능 명세를 더 잘 이해하고 모호함을 지워나가야한다.
예외적인 상황을 생각하고 복잡한 상황의 구체적 예시를 도출할 수 있어야 하는데,
이를 위한 대화는 언제나 주요한 역할을 한다.
참고 도서
http://www.yes24.com/Product/Goods/89145195
테스트 주도 개발 시작하기 - YES24
TDD(Test-Driven Development)는 테스트부터 시작한다. 구현을 먼저 하고 나중에 테스트하는 것이 아니라 먼저 테스트를 하고 그다음에 구현한다. 구현 코드가 없는데 어떻게 테스트할 수 있을까? 여기
'Study > TDD' 카테고리의 다른 글
| TDD - 대역 (0) | 2023.02.08 |
|---|---|
| TDD - 테스트 코드의 구성 (0) | 2023.02.03 |
| TDD - JUnit 5 기초 (0) | 2023.01.25 |
| TDD - 테스트 코드 작성 순서 (0) | 2023.01.12 |
| TDD - TDD(Test-Driven Development)란? (0) | 2023.01.06 |