TDD 학습과 후기

 

일단 개인적인 후기

 

먼저 요구사항을 분석하고 기능 목록과 예외 사항을 작성했다. 이를 통해 예외 사항을 처리하면서 기능 목록을 잡으려고 했다. 그랬더니 자연스럽게 역할 설계로 이어졌다. 내가 만들어낸 코드를 빠르게 피드백받고 리팩터링 할 수 있다는 점이 TDD의 장점인 것 같다.

 

테스트가 개발을 주도한다. 그리고 지속적으로 코드 정리하면서 너무 지저분해지는 걸 막는다. 빠른 피드백을 받을 수 있어서, 바로 내가 완성된 코드가 올바른지 알 수 있다. 중요한 점은 테스트를 통과할 만큼만 코드 작성하는 거다.

 

처음 하면 어렵다. 단위 테스트 작성하는 것도 어색하고 어려운 내게, 테스트로 개발을 시작하는 건 어려웠다. 하지만 TDD의 장점을 알게 되고 연습하고자 마음먹었던 것 같다.

 

 

테스트

테스트란 무엇일까? 테스트를 할 수 있다는 건 개발을 거의 완료했다는 걸 의미한다.

즉, 프로그램이 거의 사용 가능 상태이고, 개발 배포 상태이며, QA 전 상태이다.

 

개발 완료에 필요한 개발 활동으로는

요구분석/설계 + 코딩 + 검증 + 버그 수정 + 요구변경 반영이 있겠다.

 

우리는 개발 완료에 들어가는 시간을 줄이려면, 다음과 같이 할 수 있다.

• 요구분석/설계 결과가 고객 요구에 가까울 수록 요구 변영 감소
• 요구분석을 제대로 하지 못하면 버그 증가
• 검증을 잘할수록 버그 수정 감소
• 코딩력 자체도 중요

 

기능 검증은 개발자의 몫

 

검증 범위는 대개 정상 상황과 예외 상황을 합쳐서 통칭한다.

 

정상 상황이란, 입력값이 완벽하고 데이터가 완전하게 존재하는 상황

예외 상황이란, 입력값이 올바르지 않고, 데이터가 존재하지 않는 상황이다.

 

수동 테스트와 자동 테스트

TDD에서 자동화된 테스트가 중요한 역할을 한다. 수동으로 테스트를 수행하면 검증 범위를 누락하기 쉽고 예외 상황을 검증하기 어려워진다. 하지만 자동화된 테스트는 실행 가능하며 코드의 변경으로 인한 문제를 빨리 감지할 수 있다.

 

테스트 종류로는 UI 및 e2e 테스트, 서비스 통합 테스트, 그리고 단위 테스트가 있으며, 각각의 테스트 유형은 프로젝트의 다른 측면을 검증한다. 

 

먼저 UI 및 e2e 테스트는 사용자와의 접점이다. 모든 게 완벽하고 프로그램에 대한 확신이 높고 테스트 범위 증가한다.

그리고 단위 테스트는 일부 테스트 가능하며 빠르고 메서드 단위로 이루어진다.

 

 

 

TDD(테스트 주도 개발)이란?

 

주로 다음과 같은 프로세스가 진행된다.

 

1. 실패하는 테스트 케이스 코드를 작성합니다.
2. 테스트를 통과할 만큼의 코드를 구현합니다.
3. 코드를 정리하고 개선합니다.

 

이 프로세스를 원하는 기능을 완성할 때까지 반복하면 된다.

 

테스트 코드 작성 순서는 쉬움/예외에서 어려움/정상으로 가는 걸 추천한다.

 

암호 검사를 예로 들어보자.

 

• 입력값이 올바르지 않다(예외적인것)
• 모두 충족하는 경우
• 셋 중 둘 충족하는 경우
• 모두 충족하지 않는 경우

우리는 쉬운 것부터 해보자. 왜냐면 어렵거나 정상적인 테스트부터 만들면 꼬일 수가 있다. ex) 입력값은 정상적이어야 한다.

 

어려우면 시간이 오래 걸려 피드백이 느려진다. 그리고 예외적인 상황을 뒤에서 테스트하면 이미 구현한 코드에 영향이 간다.

 

• 회원 가입 예로 들어보면,

동일 이메일이 이미 존재하면 VS 동일 이메일이 존재하지 않으면

• 회원 주소 변경 예로 들어보면

회원이 없는 경우 VS 회원이 있는 경우

 

전자로 시작하는 것이 빠르게 개발할 수 있고 범위가 좁아 수월하다.

 

완급 조절이 필요

TDD로 통과시키는 과정에서

 

먼저, 정해진 값을 리턴하고자 한다. 그다음 값 비교를 이용해서 정해진 값을 리턴한다. 구현이 생각나면, 구현을 일반화한다.

 

하지만 빠르게 구현해야 하고 앞서 가면 안 된다. 구현이 막히면 다시 뒤로 돌아와서 천천히 진행한다.

앞서가면 넘어진다.

 

설계를 지원한다

기능 명세 → 설계 연결 (이름, 파라미터, 리턴 타입)

 

테스트를 하기 위해선, 대상이 필요하다. 대상의 이름이 필요하며, 어떤 값을 받고 어떤 타입을 리턴해야 하는지 결정해야 한다. 이는 자연스럽게 설계 과정으로 이어진다.