TDD란

테스트 주도 개발 (Test-driven Development)

대부분의 기존 개발 흐름

1. 만들 기능에 대한 설계
2. 코드 작성
3. 테스트

기존 개발 흐름의 문제점 : 2에서 한번에 복잡한 기능을 만들면, 오류가 많이 발생한다. 그렇게 되면 디버깅을 위한 로그 메시지를 추가하고 개발 도구가 제공하는 디버거를 이용해서 코드를 한 줄씩 따라가면서 원인을 찾는다. 이런 방식은 많은 시간이 걸린다.

TDD 순서

1. 설계 및 테스트 케이스 작성

2. 테스트 (기능이 올바르게 동작하는지 검증하는 테스트 코드를 작성, 이 때 테스트를 작성하는 과정에서 구현을 생각하지 않고 단지 테스트를 통과할 만큼만 코드 작성)

3. 테스트를 통과한 뒤에는 개선할 코드가 있으면 리팩토링 (테스트 코드 자체도 리팩토링 대상)

4. 리팩토링을 수행한 뒤에는 다시 테스트를 실행해서 기존 기능이 망가지지 않았는지 확인

TDD 장점

1. 테스트 코드가 있으면 리팩토링을 보다 과감하게 진행할 수 있다.

   • 잘 동작하는 코드를 수정하는 것은 심리적으로 불안감을 주지만, 해당 기능이 온전하게 동작한다는 것을 검증해주는 테스트가 있으면 코드 수정에 대한 심리적 불안감을 줄여준다.

2. 코드 수정에 대한 피드백이 빠르다

   • 새로운 코드를 추가하거나 기존 코드를 수정하면 테스트를 돌려서 해당 코드가 올바른지 바로 확인할 수 있다.

3. 유지보수 비용을 낮춘다.

테스트 코드 작성 규칙

• 구현하기 쉬운 테스트부터 시작!

• 쉬운 경우에서 어려운 경우로 진행

• 예외적인 경우에서 정상인 경우로 진행

• 구현이 막히면 과감하게 코드를 지우고 미련 없이 다시 시작하는 것도 하나의 방법

• 최대한 어려운 경우를 나중에 시작한다. 왜냐하면 어려운 경우를 통과시키기 위한 테스트를 만들면, 한 번에 구현해야 할 코드가 많아진다. 그럼 나도 모르게 버그를 만들고 나중에 버그를 잡기 위해 또 시간이 들여진다.

• 예외 상황을 먼저 테스트해야 하는 이유는 예외 상황을 초반에 전혀 고려하지 않은 코드에 예외 상황을 반영하려면 코드의 구조를 뒤집거나 코드 중간에 예외 상황을 처리하기 위해 조건문을 중복해서 추가하는 일이 벌어진다. 이는 코드를 복잡하게 만들어 버그를 만들 수 있다.

TDD 처음 구현할 때 따라하면 좋은 순서

1. 정해진 값을 리턴
2. 값 비교를 이용해서 정해진 값을 리턴
3. 다양한 테스트를 추가하면서 구현을 일반화

• 한번에 많은 코드를 구현하기 보다는 단계적으로 조금씩 구현해 나간다.
• 처음에는 정확한 수(상수 ex. "Abcd123!@".equals() )나 정확한 예시를 넣어서 비교하면서 테스트를 통과하고, 통과한 다음에 상수를 제거하고 변수를 사용해서 일반화한다.
• 일단 동작하는 코드를 만드는 능력도 중요하지만, 소프트웨어가 개선되는 방향에 따라 코드를 잘 변경할 수 있는 능력도 중요하다.

리팩토링의 목적

• 코드를 잘 변경하기 쉬운 구조를 만들기 위함

리팩토링 주의사항

• 리팩토링 범위가 크면 리팩토링에 실패할 확률이 높아진다.
  - 범위가 큰 리팩토링을 하기 전에 코드를 커밋하거나 별도 브랜치에서 작업 한다.