소개

테스트 중심 개발은 잘 테스트되고 리팩터링 가능한 코드를 보장하는 효과적인 방법입니다. 기본 아이디어는 테스트를 작성하여 개발을 시작한다는 것입니다. 이러한 테스트는 기대치를 명확하게 문서화하고 성공적인 구현을 위한 기준표를 만듭니다. 제대로 수행되면 코드를 작성하기 전에 예상되는 함수의 입력/출력을 명확하게 정의할 수 있습니다. 이는 몇 가지 즉각적인 이점을 제공합니다:

• 코드와의 상호작용을 위한 인터페이스를 신중하게 고려하고 테스트 가능하도록 설계합니다.
• 코드 작성을 시작할 때 수동 테스트나 결과 예측을 위한 실행 로직의 단계별 실행으로 인해 흐름이 중단되지 않습니다. 대신에 테스트만 실행하면 됩니다
• 테스트 합격은 달성하기에 만족스러운 목표가 됩니다. 프로세스를 잘 정의되고 달성 가능한 일련의 마일스톤으로 나누면 작업이 더욱 즐거워집니다.
• 코드 테스트를 방해할 수 있는 구현 후 게으름과 지나친 자신감을 피하세요.

이제 이점을 확신했으므로 다음 단계에 따라 테스트 기반 개발(TDD)을 시작할 수 있습니다.

1. 테스트 작성 또는 수정
2. 테스트 실패 여부 확인
3. 테스트를 통과하기 위한 최소한의 코드 작성

이러한 단계는 순환적으로 수행되므로 항상 현재 구현에 도전하기 위해 더 많은 테스트를 추가하게 됩니다.

최소한의 코드 작성을 지정하는 마지막 단계는 엄격하게 따르면 작업이 지루해질 수 있는 단계입니다. 이 규칙을 벗어나는 것이 적절한 시기를 결정하기 전에 이 규칙이 존재하는 이유를 이해하는 것이 중요합니다.

간단한 예

당신은 Add(x, y int) int 함수를 구현해야 합니다. 구현으로 이동하여 x y를 반환하기 전에 가장 간단한 테스트인 1 1 == 2를 작성하세요. 그러면 테스트를 통과할 수 있는 가장 간단한 구현은 무엇입니까? 2를 반환합니다. 이제 테스트가 통과되었습니다!

이 시점에서 더 많은 테스트가 필요하다는 것을 깨닫고 속도를 높여 몇 가지 테스트를 더 추가합니다.

• 1 2 == 3
• 100 5 == 105

이제 테스트가 실패하므로 구현을 수정해야 합니다. 이번에는 그냥 3을 반환하거나 105를 반환할 수 없으므로 모든 테스트에 작동하는 솔루션을 찾아야 합니다. 이는 다음 구현으로 이어집니다. return x y.

사소한 예에서는 이것이 지나치게 지루하게 느껴지지만 이 방법을 엄격하게 준수하면 구현을 신뢰하는 대신 여러 테스트를 작성하게 됩니다. 물론, x y를 반환하려는 초기 아이디어는 효과가 있었을 것입니다. 그러나 중요한 점은 코드에 대한 자신의 이해보다는 테스트에 의존하도록 스스로를 재교육하는 것입니다. 현실 세계에서는 이 코드를 작업하는 사람이 여러분뿐만이 아니며 필연적으로 구현 세부 사항을 잊어버리게 됩니다. 이 프로세스를 통해 더 많은 테스트를 작성하고 단순한 구현을 깨는 더 많은 방법을 생각하게 됩니다.

결국 경험을 쌓고 직면하는 다양한 시나리오에서 작동하는 균형을 찾는 방법을 배우게 됩니다. 기능의 최고 속도 구현으로 돌아가서 버그가 적고 유지 관리 가능한 코드가 더 많이 작성된다는 사실을 알게 될 것입니다.

HTTP API에 대한 단계별 TDD

HTTP REST API에 TDD를 사용하는 좀 더 복잡한 예를 살펴보겠습니다. 이 단계별 가이드에서는 내 Go 프레임워크인 babyapi를 사용하지만 개념은 어디에나 적용될 수 있습니다.

babyapi는 제네릭을 사용하여 Go 구조체를 중심으로 전체 CRUD API를 생성하므로 전체 REST API 및 클라이언트 CLI를 매우 쉽게 생성할 수 있습니다. 이 외에도 babytest 패키지는 엔드투엔드 API 테이블 테스트를 생성하기 위한 몇 가지 도구를 제공합니다. API 수준에서 TDD를 사용하면 새로운 API 또는 기능의 HTTP 및 스토리지 계층을 한 번에 완벽하게 테스트할 수 있습니다.

면책 조항: babyapi는 대부분의 구현을 처리하고 테스트 상용구를 생성하는 데에도 사용되므로 기술적으로 TDD로 시작하지 않습니다. 하지만 API에 PATCH 요청에 대한 지원을 추가하면 얼마나 유익한지 살펴보겠습니다.

1. 새 Go 프로젝트 만들기
   

2. babyapi의 간단한 예를 사용하여 초기 main.go 생성
   

3. CLI를 사용하여 테스트 상용구 생성
   

4. 자리 표시자를 예상 JSON으로 채워 각 테스트를 구현합니다.
   

5. 테스트를 실행하고 테스트가 통과하는지 확인하세요!

6. PUT은 멱등적이므로 모든 필드가 포함되어야 합니다. 이를 방지하기 위해 Completed with PATCH 요청 전환에 대한 지원을 추가하려고 합니다. 이 기능이 어떤 모습일 것으로 기대하는지에 대한 간단한 테스트를 추가하는 것부터 시작합니다.
   

7. babyapi는 기본적으로 PATCH를 지원하지 않으므로 이 테스트는 실패합니다. TODO 구조체에 대한 패치를 구현하여 이 문제를 해결할 수 있습니다. 두 가지 테스트로 기능을 정의했으므로 가장 간단한 구현은 Completed = true로 설정하는 것이 아니라 요청
   의 값을 사용해야 합니다.

8. 이제 TODO의 완료 상태를 변경할 수 있지만 이 새로운 테스트 세트에서 볼 수 있듯이 여전히 PATCH를 사용하여 다른 필드를 수정할 수는 없습니다.
   

9. 패치를 업데이트하여 나머지 필드 설정
   

10. TODO가 비어 있더라도 요청 필드로 항상 TODO를 업데이트하므로 테스트는 여전히 실패합니다. 빈 값을 확인하도록 구현을 업데이트하여 이 문제를 해결하세요
    

11. 새로운 UpdateWithPatch 테스트는 통과했지만 이전 테스트는 실패했습니다. Completed를 *bool로 변경했으므로 빈 값으로 생성된 TODO는 null
    로 표시됩니다.

12. nil을 false로 처리할 수 있도록 TODO에 대한 렌더링을 구현합니다.
    

테스트 중심 개발로 PATCH 기능을 구현하면 강력한 테스트 세트와 잘 구현된 기능이 탄생했습니다. 테스트에서는 PATCH 요청의 예상 입력과 출력을 정의하는 것부터 시작했기 때문에 요청에서 빈 값을 확인하지 않아 발생하는 문제를 쉽게 확인할 수 있었습니다. 또한 기존 테스트에서는 Completed 유형을 *bool

결론

테스트 중심 개발은 완벽하게 테스트되고 올바른 코드를 작성하기 위한 효과적인 접근 방식입니다. 테스트를 염두에 두고 시작하면 테스트를 나중에 고려하지 않고 모든 코드가 테스트 가능하도록 설계할 수 있습니다.

TDD 채택을 주저한다면 시작하기 위한 몇 가지 아이디어는 다음과 같습니다.

• 함수의 입력/출력이 명확하고 구현이 지나치게 복잡하지 않은 간단한 시나리오에서 시도해 보세요. 발생할 수 있는 다양한 입력/출력에 대한 강력한 테이블 테스트를 작성할 수 있습니다. 다양한 시나리오를 명확하게 시각화하면 구현을 단순화할 수 있습니다
• 새로운 버그를 수정하고 있다면 이미 테스트에서 공백을 식별한 것입니다. 처음에 이 버그를 식별했을 테스트를 작성하는 것부터 시작하세요. 그런 다음 기존 테스트를 중단하지 않고 이 테스트를 통과하도록 하세요.
• babyapi 예시와 유사하게, 상위 수준 API 테스트에 TDD를 사용할 수 있습니다. 예상되는 요청/응답을 정의한 후에는 구현의 보다 세부적인 부분에 대해 일반적인 개발 흐름을 재개할 수 있습니다.

TDD가 코드 작성 방식에 적합하지 않더라도 여전히 갖고 있어야 할 강력한 도구입니다. 최소한 시간을 내어 시험해보고 이것이 개발 프로세스에 어떤 영향을 미치는지 확인하시기 바랍니다.