TDD의 중요성

Source: Dev.to

The Problem

나는 12개의 매개변수를 가진 “멋진” API를 만들었다.
그것은 형편없었다.
내 머릿속을 박사 수준으로 이해하지 못하면 아무도 사용할 수 없었다.

수년간 백엔드 개발을 하면서, 나는 Test Driven Development (TDD)를 힘들게 배웠다. 나는 데이터를 얻기 위해 매개변수 하나씩 계속 추가하며 깊은 숲속에 파묻혀 코딩하고 있었다. 드디어 테스트를 작성했을 때, 현실이 다가왔다:

• 호출자는 내가 요구한 절반도 갖고 있지 않았다.
• 내 “아름다운” API는 쓸 수 없었다.

가장 중요한 사람, 즉 사용자를 잊고 있었다.

What TDD Changes

TDD는 이 역방향 사고를 뒤집는다. 존재하기를 바라는 코드에 대한 테스트를 먼저 작성하고, 그 테스트를 통과하도록 코드를 만든다.

1. Red – 실패하는 테스트를 작성한다.
2. Green – 테스트를 통과시키기에 충분한 코드를 구현한다.
3. Refactor – 테스트가 여전히 초록색인 상태에서 코드를 개선한다.

반복한다.

Benefits

• 컴파일러가 아니라 호출자 입장에서 생각하도록 강제한다.
• 나중에 발생하는 대규모 디버깅 시간을 절감한다.
• 테스트 케이스는 라이브러리가 업데이트되거나 팀원이 변경을 가할 때 안전망이 된다.

“구축할 가치가 있다면 테스트할 가치도 있다. 테스트할 가치가 없다면 왜 시간을 낭비하겠는가…”