TDD & Unit test

Unit test?

'단위 테스트'

단위 테스트(Unit Test)는 하나의 모듈을 기준으로 독립적으로 진행되는 가장 작은 단위의 테스트입니다. 여기서 모듈은 애플리케이션에서 작동하는 하나의 기능 또는 메서드로 이해할 수 있습니다.

• 예를 들어 웹 애플리케이션에서 로그인 메서드에 대한 독립적인 테스트가 1개의 단위 테스트가 될 수 있습니다.
• 즉, 단위 테스트는 애플리케이션을 구성하는 하나의 기능이 올바르게 동작하는지를 독립적으로 테스트하는 것으로, "어떤 기능이 실행되면 어떤 결과가 나온다" 정도로 테스트를 진행합니다.

TDD?

'테스트 주도 개발' (Test Driven Development)

TDD는 매우 짧은 개발 사이클의 반복에 의존하는 소프트웨어 개발 프로세스입니다. 우선 개발자는 요구되는 새로운 기능에 대한 자동화된 테스트 케이스를 작성하고 해당 테스트를 통과하는 가장 간단한 코드를 작성하고 상황에 맞게 리팩터링 하는 과정을 거치는 것입니다. 말 그대로 테스트를 우선시하는 개발방식인 것입니다.

🤷‍♀️ 예시

• 예를 들어, 덧셈 프로그램
• add 함수를 만들기 전에 반드시 실패하는 testAdd 함수를 먼저 작성한 뒤, 테스트가 성공하게 만드는 add 함수를 작성하도록 합니다.

• int testAdd(){
    assert 5+4 == add(5,4)
    assert -4+9 == add(-4,9)
  }

• 테스트에 요구사항이 제대로 동작함을 입증할 수 있는 코드를 작성하고 이 테스트를 만족하는 실제 프로그램을 써나가는 것이 TDD입니다.

🍩 얻을 수 있는 것

• 보다 튼튼한 객체 지향적인 코드 생산
  테스트 코드를 먼저 작성한다는 것은 하나하나의 기능들에 대해서 철저히 구조화시켜 코드를 작성한다는 것을 뜻합니다. 이는 종속성과 의존성이 낮은 모듈로 조합된 소프트웨어 개발을 가능하게 하며 필요에 따라 모듈을 추가하거나 제거해도 소프트웨어 전체 구조에 영향을 미치지 않게 됩니다.
• 재설계 시간의 단축
  테스트 코드를 먼저 작성하기 때문에 개발자가 지금 무엇을 해야 하는지 분명히 정의하고 개발을 시작하게 됩니다. 또한 테스트 시나리오를 작성하면서 다양한 예외사항에 대해 생각해볼 수 있습니다. 이는 개발 진행 중 소프트웨어의 전반적인 설계가 변경되는 일을 방지할 수 있습니다.
• 디버깅 시간의 단축
  이는 유닛 테스팅을 하는 이점이기도 합니다. 예를 들면 사용자의 데이터가 잘못 나온다면 DB의 문제인지, 비즈니스 레이어의 문제인지, UI의 문제인지 실제 모든 레이어들을 전부 디버깅해야 하지만, TDD의 경우 자동화된 유닛 테스팅을 전재하므로 특정 버그를 손쉽게 찾아낼 수 있습니다.
• 테스트 문서의 대체 가능
  개발자가 기대하는 애플리케이션의 동작에 관한 문서를 테스트가 제공해줍니다. 이 테스트 케이스는 코드와 함께 업데이트되므로 문서 작성과 거리가 먼 개발자에게 매우 좋습니다.
• 추가 구현의 용이함
  개발이 완료된 소프트웨어에 어떤 기능을 추가할 때 가장 우려되는 점은 해당 기능이 기존 코드에 어떤 영향을 미칠지 알지 못한다는 것입니다. 하지만 TDD의 경우 자동화된 유닛 테스팅을 전제하므로 테스트 기간을 획기적으로 단축시킬 수 있습니다.

🤔 좋기만 할까?

• 코드 생산성
  두 배는 아니더라도 분명 코드량이 늘어납니다. 비즈니스 로직, 각종 코드 디자인에도 시간이 많이 소요되는데, 거기에다가 테스트 코드까지 작성하기란 여간 벅찬 일이 아닐 것입니다. 코드 퀄리티보다는 빠른 생산성이 요구되는 시점에서 TDD는 큰 걸림돌이 될 수 있습니다.
• 테스트 코드를 작성하기가 쉬운가?
  진입 장벽이 존재합니다. 어떠한 부분을 테스트해야 할지, 어떻게 테스트해야 할지, 여러 테스트 프레임워크 중 어떤 것이 우리의 서비스와 맞는지 등 여러 부분들에 대한 학습이 필요하고 익숙해지는 데에도 시간이 걸립니다. 팀에서 한 명만 익숙해진다고 해결될 일이 아닙니다. 개발은 팀 단위로 수행되기 때문에 팀원 전체의 동의가 필요하고 팀원 전체가 익숙해져야 비로소 테스트 코드가 빛을 발하게 되는 것입니다.

📝 결론

• TDD를 활용하면 테스트 케이스를 설계하기 위한 초기 비용이 확실히 더 들게 됩니다. 하지만 개발 과정에 있어서 '초기 비용'보다 '유지보수 비용'이 더 클 수 있다는 것을 명심해야 합니다.
• 만약 어떤 부분에 대한 결과가 뻔하다면 TDD를 하지 않아도 됩니다. 또한 TDD를 했을 때 얻는 것이 적다면 TDD를 하지 않아도 됩니다.
• 그럼 언제 해
  1. 나에 대한(내부적인) 불확실성이 높은 경우
     👉 처음 해보는 프로그램 주제
  2. 외부적인 불확실성이 높은 경우
     👉 개발하는 중에 코드를 많이 바꿔야 된다고 생각하는 경우
     👉 내가 개발하고 나서 이 코드를 누가 유지 보수할지 모르는 경우
     👉 고객의 요구조건이 바뀔 수 있는 프로젝트
  즉, 불확실성이 높을 때 TDD를 하면 됩니다.

TDD와 Unit Test

TDD는 테스트보다는 코드 설계에 더 집중되어있습니다. TDD와 단위 테스트의 차이는 테스트 코드를 작성하는 시점의 차이.

TDD와 달리 단위 테스트 코드는 보통 개발 코드를 작성하고, 기능 테스트를 위해 테스트 코드를 작성하여 테스트를 수행.

 

TDD의 결과물은 단위 테스트이다.

💭 느낀 점

✔ TDD전에 단위 테스트부터, 테스트 작성법을 익힌 후 TDD 하는 게 좋을 것 같다.

✔ TDD 까지는 아니더라도 테스트 코드를 작성하는 것은 필요하다고 생각.