TDD-목적,적용방법,주의사항,의견

TDD(Test-Driven Development)는 소프트웨어 개발 방법론 중 하나로, 테스트를 먼저 작성하고 해당 테스트를 통과할 수 있는 코드를 작성하는 방식입니다. 

이는 개발자가 코드를 작성하기 전에 해당 코드가 요구사항을 충족시키는지 확인하는 과정을 포함합니다.

 

[목차]

• 목적
• 적용 방법
• 주의해야 할 점
• 의견

목적

• 품질 향상
  • 테스트 코드를 먼저 작성하고 해당 테스트를 통과하기 위한 코드를 작성함으로써 코드의 품질을 높입니다.
• 기능 안정성
  • 테스트가 항상 통과되는 코드를 작성함으로써, 새로운 기능 추가나 기존 기능 변경 시 기능 안정성을 보장합니다.
• 리팩토링 도움
  • 코드의 변경 사항이 기존 기능을 망치지 않도록 도와줍니다. 테스트는 리팩토링 시 코드의 안정성을 보장하는데 도움이 됩니다.

적용 방법

1. 테스트 작성 
   • 새로운 기능을 추가하거나 기존 기능을 변경하기 전에 해당 기능에 대한 테스트를 작성합니다. 
   • 이 테스트는 초기에는 실패할 것입니다.
2. 테스트 통과 코드 작성
   • 테스트가 실패하는 상태에서 해당 테스트를 통과할 수 있는 최소한의 코드를 작성합니다.
3. 리팩토링
   • 작성한 코드를 리팩터링 하여 보다 가독성 있고 효율적인 코드로 변경합니다.
4. 반복
   • 위 과정을 반복하여 새로운 기능을 추가하거나 기존 기능을 변경합니다. 
   • 각각의 단계에서 테스트를 실행하여 안정성을 유지합니다.

주의해야 할 점

1. 과도한 테스트 작성 피하기
   • 모든 상황에 대한 테스트를 작성하는 것은 효과적이지 않을 수 있습니다. 
   • 필요한 테스트만 작성하도록 합니다.
2. 유연성 유지
   • 초기에 작성한 테스트가 변경이 필요할 때, 해당 테스트를 유연하게 수정할 수 있도록 합니다.
3. 테스트와 코드의 밸런스 유지: 
   • 테스트 작성이 코드 작성을 지나치게 지연시키거나 반대로 코드 작성이 테스트 작성을 무시하는 상황을 피하기 위해 밸런스를 유지합니다.

반응형

의견

코드가 있는 곳엔 언제나 테스트 코드가 함께 해야 한다.

들어보신 분도 계실 텐데 모두 중요하다고 생각하지만, 잘 운영되지는 않습니다. 

시간도 없고, 귀찮고, 인정도 못 받는 업무로 느껴지기 때문입니다. 뭐든 동기부여가 중요하지만, 테스트 코드 작성을 업무로 보기 시작하면 이렇듯 하지 못하게 되는 이유가 넘치게 많아집니다. 

업무긴 하지만, 기능을 코딩할 때 그냥 같이하는 것 정도로 볼 필요가 있습니다. 그만큼 익숙해져야 하는 것으로 보입니다. 

어려운 이야기지만, 이 또한 개발 조직의 처음부터 정착시켜야 하는 것들 중에 하나입니다. 조직이 커진 상태에서 갑자기 하려고 하면, 이래저래 말도 , 핑계도 많아져서 금방 포기하게 되게 됩니다. 

 

잘만 운영하면 테스트 코드 자체만으로도 코드를 이해하고, 서비스를 이해하는데 많은 도움이 되고, 품질 유지 및 향상에도 많은 도움이 되지만, 처음부터 존재하지 않는 테스트 코드를 작성해야 한다고 하면 다들 싫어하고 제대로 하지도 않습니다. 

왜냐면, 그 효용성을 경험해보지 않았기 때문입니다. 

더군다나, 이미 만들어진 테스트 코드가 없는 상태에서 만들기 시작할 땐 어디서부터 어떻게 만들어야 하는지 모를 수 있습니다.

 

이럴 땐, 숙련된 선배 개발자가 그 틀을 만들고, 단계적 적용 전략을 만들어 가이드해야 합니다. 

한 번에 안되니, 차근히 말입니다.