[10분 테코톡] 😼 피카의 TDD와 단위테스트

[10분 테코톡] 😼 피카의 TDD와 단위테스트

TDD(Test-Driven Development)란 뭘까?

TDD (테스트 주도 개발)는 코드를 작성하기 전에 테스트를 먼저 작성하는 개발 방법론이다.
보통은 기능을 먼저 개발한 후 테스트를 작성하는 방식이 일반적이다.
하지만 TDD는 반대로 테스트를 먼저 작성하고, 그 테스트를 통과하는 최소한의 코드를 작성하는 방식.

TDD의 핵심 사이클: "Red → Green → Refactor"

TDD는 세 가지 단계를 반복하는 과정이다.

1. Red (실패하는 테스트 작성)

• 먼저 아직 구현되지 않은 기능을 검증하는 테스트 코드를 작성한다.
• 이때 당연히 테스트는 실패한다. (왜냐하면 아직 코드를 구현하지 않았으니까!)

2. Green (테스트를 통과하는 최소한의 코드 작성)

• 실패한 테스트를 통과할 수 있도록 최소한의 코드를 작성한다.
• 여기서 핵심은 "최소한으로 동작만 하도록" 구현하는 것!!
• 완벽한 코드가 아니라 일단 테스트를 통과하는 것만 목표로 한다.

3. Refactor (코드 리팩토링)

• 테스트가 통과하면 이제 코드를 더 깔끔하게 개선 한다.
• 불필요한 코드나 중복을 제거하고 가독성을 높이도록 리팩토링 해야함.
• 중요한 점은 이 과정에서 테스트가 보장되므로 리팩토링을 안전하게 진행할 수 있다는 것!

이 세 단계를 반복하면서 점진적으로 코드를 개선하는 것이 TDD의 핵심!!

왜 TDD를 사용해야 할까?

1. 코드 품질 향상

TDD를 사용하면 테스트가 사전에 존재하기 때문에 코드가 자연스럽게 깔끔해지고 유지보수하기 쉬운 구조가 된다.
"이 코드가 정말 필요한가?" 고민하면서 개발하므로 불필요한 기능을 줄이고 효율적인 코드만 남길 수 있음.

2. 디버깅 시간 단축

버그를 초기에 발견할 수 있어서 디버깅 시간을 크게 줄일 수 있다.
보통 코드 작성 후 테스트를 하면 어디서 문제가 발생했는지 찾는 데 시간이 오래 걸리지만,
TDD는 작은 단위에서부터 점진적으로 개발하므로 문제 발생 시 즉각적으로 확인 가능하다.

3. 리팩토링이 쉬워짐

코드 변경이 필요한 경우에도 기존 테스트가 실패하면 즉시 알 수 있기 때문에 안정적으로 리팩토링할 수 있다.

4. 개발 속도가 빨라질 수도 있음

처음에는 TDD가 개발 속도를 늦추는 것처럼 보일 수도 있지만 버그 수정, 유지보수, 리팩토링의 부담이 줄어들면서 장기적으로는 훨씬 빠르고 안정적인 개발이 가능.

TDD를 실패하는 이유?

TDD를 실패하는 사람이 하는 테스트

• 코드가 이루고자 하는 가치나 기능을 테스트하기보다 그 기능을 어떻게 구현하고 있는지를 테스트한다.
• 결국 테스트 케이스들이 구현체와 결합도가 높아진다.
• 구현체들을 리팩토링하면 결합되어있는 테스트 케이스들이 모두 깨져버린다.

단위 테스트(Unit Test)란?

먼저 프로그램 전체 테스트를 살펴보자면 테스트는 크게 인수, 부합, 기능, 통합, 단위 테스트가 존재하는데, 여기서 소개하는 단위테스트를 제외한 나머지 4개의 테스트는 제일 기본적인 단위테스트로부터 점점 더 범위를 넓혀나가며 테스트를 하게 된다.

이 중에서 단위 테스트는 가장 작은 단위의 테스트다.
단위 테스트는 프로그램의 개별 단위(함수, 메서드 등)가 올바르게 동작하는지 검증하는 테스트다.
쉽게 말하면 "이 함수가 정상적으로 동작하는지 테스트하는 것" !!

단위 테스트의 목적

1. 문제점 발견
   단위 테스트는 각 단위가 정확하게 동작하는지 검사하고, 문제가 발생 시 어느 부분이 잘못되었는지 재빨리 확인 가능.
   따라서 프로그램 안정성이 높아진다.

2. 변경이 쉽다.
   어떻게 코드를 고치더라도 문제점을 금방 파악할 수 있고, 수정된 코드가 정확하게 동작하는지 쉽게 알 수 있게되므로 변경을 자주 할 수 있다.

3. 품징 향상
   하나의 단위 테스트가 너무 길어지거나 복잡해지는 것은 프로덕션 코드에서 잘못되었다고 생각할 수 있다. 하나의 테스트 메서드에서 너무 많은 기능을 수행하기 때문에 이는 리팩토링이 필요하다는 것을 바로 알 수 있다.

4. 코드의 문서화
   일명 샘플코드라고도 한다. 예외 상황, 용도, 의존 관계를 한 눈에 파악할 수 있다.
   또한 단위테스트는 배포되는 코드와 일치하므로 항상 최신 상태로 유지된다는 이점도 있다.

좋은 단위 테스트

1. 첫번째는 빠르게! 테스트는 빨라야 한다.
   테스트가 느리면 자주 돌릴 엄두를 못 내겠죠?
   그렇게 되면 문제를 빨리 찾아내 고치지 못하고 결국 코드 품질이 망가짐..ㅠㅠ

2. 각 테스트는 의존하면 안된다. 테스트가 서로 의존하게 되면 하나가 실패할 때 도미노처럼 나머지도 잇다라 쭉 실패할 것이다.
   그렇게 되면 원인을 진단하기 어려워지며 후반 테스트가 찾아낼 결함이 숨겨지겠죠..

3. 테스트는 어떤 환경에서도 반복이 가능해야 한다.
   실제환경, QA환경, 네트워크가 연결되어 있지 않은 노트북 환경에서도 실행할 수 있어야한다!
   테스트가 돌아가지 않는 환경이 하나라도 있다면 테스트가 실패하는 이유를 둘러댈 변명이 생기고 환경이 지원되지 않기에 테스트를 수행하지 못하는 상황에 직면하게 된다.

4. 테스트는 Boolean 값으로 결과를 내야 한다. 테스트는 성공 아니면 실패를 무조건 반환해야함. 테스트가 스스로 성공과 실패를 가늠하지 않는다면 판단은 보는 사람이 주관적으로 판단하게 되고, 그러면 지루한 수작업 평가가 필요하게 되겠죠..

5. 테스트는 항상 적시에 작성해야 한다. 단위 테스트는 테스트를 하려는 실제 코드를 구현하기 직전에 구현해야 한다.
   만약 실제 코드를 구현한 다음 테스트 코드를 만들게 되면 실제 코드가 테스트 하기 어렵다는 사실을 뒤늦게 발견할지도 모른다.

개발을 하기 전에 테스트 코드를 먼저 작성하라는 말의 이유를 자세하고 정확히 알게 된 영상이다.
당연히 내가 완벽하게 이해 하진 못했지만 TDD에 대해서 기억나지 않을 때 언제든지 두고 두고 볼 수 있는 내용!
처음에는 생소할 수 있지만 꾸준히 연습하면 개발 효율성이 올라가는 것을 체감할 수 있을 것 같다.

참고하면 좋을 벨로그