TIL 정리_53(TDD)

 

TDD란?

Test Driven Development의 약자로 테스트 주도 개발이라고 한다

작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다

짧은 개발 주기의 반복에 의존하는 개발 프로세스이며,

프로토 타입을 완성하는 애자일 방법론 중 하나인 Test-First 개념에 기반을 두었다 

 

 

 

 

TDD 개발주기

단위 테스트 : 말 그대로 한 단위(일반적으로 class)만을 테스트 하는 것이다.

• Write Failing Test 단계 : 실패하는 테스트 코드를 먼저 작성한다
• Make Test Pass 단계 : 테스트 코드를 성공시키기 위한 실제 코드를 작성한다
• Refactor 단계 : 중복 코드 제거, 일반화 등의 리팩토링을 수행한다

중요한 것은 실패하는 테스트 코드를 작성할 때까지 실제 코드를 작성하지 않는 것과

실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성해야 하는 것이다.

>>실제 코드에 대해 기대되는 바를 보다 명확하게 정의함으로써 불필요한 설계를 피할 수 있고, 정확한 요구사항에 집중할 수 있다

 

 

 

일반 개발과 TDD 개발 방식의 비교

 

일반 방식

디자인 – 코드개발 – 테스트(다시 디자인 수정)

이 방식은 소프트웨어 개발을 느리게 하는 잠재적 위험이 존재한다

 

위험이 존재하는 이유 

소비자의 요구사항이 처음부터 명확하지 않을 수 있다

->그렇기에 처음부터 완벽한 설계는 어렵다

자체 버그 검출능력 저하 또는 소스코드의 품질이 저하될 수 있다

자체 테스트 비용이 증가할 수 있다

이런 문제점들이 발생되는 이유는 어느 프로젝트든 초기 설계가 완벽하다고 말할 수 없기 때문에 

재설계로 인해 개발자가 코드를 삽입, 수정, 삭제하는 과정에서 불필요한 코드가 남거나 중복처리가 될 가능성이 크다

 

결론적으로 유지보수가 힘들고 자체 테스트 비용이 증가한다 

 

 

 

TDD개발 방식

테스트 코드를 작성한 뒤에 실제 코드를 작성한다 

TDD의 대표적인 Tool : Junit //java단위 테스트 프레임워크

 

 

TDD 개발 방식의 장점

• 보다 튼튼한 객체지향적인 코드를 생산할 수 있다 (불필요한 코드 
• 추가 요구사항이 생기더라도 실시간으로 반영할 수 있다
• TDD는 코드의 재사용 보장을 명시하므로 TDD를 통한 소프트웨어 개발 시 기능 별 철저한 모듈화가 이뤄진다.
• -> 종속성과 의존성이 낮은 모듈로 조합된 소프트웨어 개발을 가능하게 하며 필요에 따라 모듈을 추가하거나 제거해도 소프트웨어 전체 구조에 영향을 미치지 않는다

 

• TDD 방식의 의문점

코드 생산성 문제 

코드량이 늘어나기 때문에 코드의 퀄리티보다 빠른 생산성이 요구되는 시점에서는 TDD가 걸림돌이 될 수 있다

 

테스트코드의 진입장벽

어떤 부분을 테스트할지, 어떻게 테스트해야할지 여러 테스트 프레임워크 중 어떤것이 서비스와 맞는지 등 여러 부분들에 대한 학습이 필요하고 익숙해지는데 시간이 걸린다

또한 개발은 팀 단위로 이루어지기 때문에 팀원 전체가 익숙해져야 한다

 

모든 상황에서의 필요성

TDD 방식은 모든 상황에 대해서 테스트 코드를 작성할 수 없으며 작성할 필요도 없다

또한 테스트 코드를 작성한다고 해서 버그가 발생하지 않는 것도 아니다 

 

 

개발 분야에 따른 작업방식의 차이로 TDD가 불필요하다고 판단할수도 있지만, 

의문점에 비해 장점이 확실한 방식이기 때문에 보다 높은 퀄리티의 코드를 추구한다면 적극적으로 시도해보는게 좋다