TDD( Test-Driven-Development ) 방법론이란?

면접보는데 TDD몰라서 어버버해서 정리

TDD

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

반복 테스틀를 이용한 S/W방법론으로, 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다.

TDD 개발주기

• RED 단계에서는 실패하는 테스트 코드를 먼저 작성한다.
• Green 단계에서는 테스트 코드를 성공시키기 위한 실제 코드를 작성한다.
• Yellow 단계에서는 중복 코드 제거, 일반화 등의 리팩토링을 수행한다.

테스트 코드를 작성할 떄까지 실제 코드를 작성하지 않는 것과, 실패하는 테스트를 통과할 정도의 최소 실제코드를 작성해야 하는것이 중요하다. 이를 통해 실제 코드에 대해 기대되는 바를 보다 명확하게 정의함으로써 불필요한 설계를 피할 수 있고, 정확한 요구 사항에 집중할 수 있다.

일반 개발 방식

보통의 개발 방식은 ‘ 요구사항분석 -> 설계 -> 개발 -> 테스트 -> 배포’의 형태를 갖는다. 이러한 방식은

1. 소비자의 요구사항이 처음부터 명확하지 않을 수 있다.
2. 따라서 처음부터 완벽한 설계는 어렵다.
3. 자체 버그 검출 능력 저하 또는 소스코드의 품질이 저하될 수 있다.
4. 자체 테스트 비용이 증가 할 수 있다.

-> 코드의 재사용이 어렵고 관리가 어려워진다.

TDD

TDD와 일반적인 개발 방식의 차이점은 테스트 코드를 작성한 뒤에 실제 코드를 작성한다는 점이다.

디자인(설계) 단계에서 프로그래밍 목적을 반드시 미리 정의애햐만 하고, 또 무엇을 테스트할지 미리 정의(테스트 케이스 작성) 해야 한다.

테스트 코드를 작성하는 도중에 발생하는 예외 사항들은 테스트 케이스에 추가하고 설계를 개선한다.

이후 테스트가 통과된 코드만을 코드 개발 단계에서 실제 코드로 작성한다.

-> 이러한 반복적인 단계가 진행되면서 자연스럽게 코드의 버그가 줄어들고 , 소스코드는 간결해진다.

TDD의 장점

• 객체 지향적인 코드 생산 : TDD코드의 재사용 보장을 명시하면서 TDD를 통한 소프트웨어 개발시 기능별 철저한 모듈화가 이뤄진다.

• 재설계 시간 단축(오버 엔지니어링방지) : 간혹 계획하지 않았던 코드를 추가하는경우가 있는데 TDD는 테스트를 통과하기 위한 최소한 코드로 작성및 개선하고 기능 단위로 테스트를 진행하기 때문에 문제가 발견되지 않은 코드에 영향을 줄 수 있는 오버코딩을 하지 않는다.

• 디버깅 시간 단축

• 테스트 문서의 대체 가능

• 추가 구현의 용이함

TDD의 단점

• 생산성 저하 : 코드를 2개 짜야함.

이게 무슨말인지.. 쉽게 이해가 안됨

테스트 주도 개발 -> 개발을 하는 데 테스트가 주가 되어 개발한다는 뜻인가봄 , 
테스트 코드를 작성하며 결과를 예상해볼 수 있기에 설계의 문제로 인한 오류 개선 속도가 빨리질거임 -> TDD의 큰 장점

모듈별로 테스트코드를 작성하고 테스트 통과하면 실제 개발을 하라는거같은데 

junit..이거 맨날 쓰던건데

ex) 더하기 하는 프로그램이 구현할때
일반적 방식 -> 1과 2를 입력하는걸 구현하고 더하는걸 구현해서 3이 출력 되게 한다.
TDD -> 1,2을 더하는걸 구현 그후 테스트코드작성 -> 테스트 코드가 돌아가는 코드 작성(1,2 입력하는거랑, 출력하는거) -> 리팩토링