블로그 이전했습니다!
https://computasha.com/Clean+Code/테스트/TDD(Test-Driven+Development)+개념과+장단점



✨ 오늘의 목표 : TDD 이해하기


👩‍💻 TDD란?

TDD(Test-Driven Development)는 테스트가 코드 작성을 주도하는 개발 방식이다.

요구 사항에 따른 자동화된 테스트케이스를 작성한 후,
해당 테스트를 통과하는 가장 간단한 코드를 작성하고 리팩토링 하는 과정의 반복이다.

새로운 기능을 추가할 때 테스트 코드를 작성함으로써, 새로운 기능이 제대로 작동함과 동시에 기존의 기능들이 잘 작동하는지 테스트를 통해 간단히 확인할 수 있다.

(기존에 소프트웨어가 먼저 개발되고 테스트 사례가 나중에 만들어지는 것과는 정반대의 방식이다!)


🔁 TDD 과정

based on the book Test-Driven Development

1. Add a test

TDD에서는, 새로운 기능을 추가하기 전에 제대로 동작하는 경우 통과하는 테스트를 먼저 작성한다.
이때 ‘제대로 동작하는 경우’를 알기 위해서 해당 기능의 요구사항과 명세서를 정확하게 이해하고 있어야 한다.
(이는 유저 케이스와 유저 스토리 등을 통해 이해할 수 있다)
이러한 방식의 이점은 개발자가 코드를 작성하기 전에 요구 사항에 집중할 수 있도록 한다는 것이다.

2. Run all tests. The new test should fail for expected reasons

작성한 테스트 코드는 기존에 예상했던 이유로 실패해야 한다. 이는 자동화된 테스트 과정(= Test Harness)이 정상적으로 동작하고 있다는 것을 알려준다. (오류가 있는 경우 잘 캐치해내는지 확인)

3. Write the simplest code that passes the new test

이제 테스트 코드를 통과하기 위한 가장 간단한 코드를 작성한다. 코드는 5번 리팩토링 단계에서 다듬어지기 때문에 여기서는 테스트만 통과한다면 못생긴 코드도 괜찮다. 다만 테스트하는 기능 이외에 다른 기능을 하는 코드를 추가하면 안 된다.

4. All tests should now pass

이제는 모든 테스트를 통과해야 한다. 만약 실패한다면, 통과할 때까지 새로 작성한 코드를 수정해야 한다.

5. Refactor as needed, using tests after each refactor to ensure that functionality is preserved

가독성과 유지보수성을 위해 코드를 리팩토링한다. 특히 하드 코딩된 테스트용 데이터는 지워야 한다. 리팩토링 후에 다시 테스트를 진행해서 기존 기능도 잘 작동하는지 계속해서 확인해야 한다.

✨ 요약하자면..

요구사항에 따라 테스트 코드 작성 -> 잘 동작하는지 확인하기 위해 실패하는 경우 확인 -> 이렇게 작성한 테스트를 통과하는 가장 심플한 코드 작성 -> 모든 테스트를 통과할때까지 코드 수정 -> 리팩토링 -> 테스트..

새로운 기능을 추가할 때마다 반복 또 반복


👍 TDD의 장점

= 높은 퀄리티의 코드

  • 반복되는 테스트를 통해 에러가 발생하지 않는 코드를 작성할 수 있다.
  • 중복되는 코드를 제거하고 코드의 재사용성을 강조하므로, 종속성과 의존성이 낮은 모듈화된 소프트웨어를 개발할 수 있다.
  • 추가적인 요구사항이 있어도 소프트웨어 전체 구조에 영향을 미치지 않고 모듈을 추가하거나 제거할 수 있다.

그 외에 개발자가 요구사항을 명확히 할 수 있고, 자동화된 유닛 테스트를 통해 버그를 상대적으로 쉽게 찾아낼 수 있다는 장점이 있다.


👎 TDD의 단점

= 생산성 저하

테스트 코드 작성으로 인해 새로운 기능을 개발하기 위한 코드량이 늘어난다.
자연스레 개발에 소요되는 시간도 늘어나는데, 코드 퀄리티보다는 빠른 생산성이 요구되는 시점에서 TDD는 적합하지 않을 수 있다.

  • 팀원 전체가 TDD 방식에 익숙해지는데도 시간이 필요하다.

🔗 참고하면 좋을 링크