TDD

TDD: Test Driven Developement, Test Driven Design

-> 테스트환경을 먼저 고려하고 개발 및 설계를 진행하는 것

이를 통해 개발 방법, 코드, 아키텍처 디자인하는 방법이 바뀐다.

 

1. 실패하는 테스트를작성한다.(다른 베이스 코드 제외하고 제일먼저)

2. 테스트를 패스할 수 있는 최소한의 코드를 작성한다.

3. 리팩토링한다.

-> 빌드 -> 실행

하다보면 최소한의 코드와 간결한 구조를 얻을수 있다.

 

실패하는 테스트

- 첫번쨰로 기능상의 테스트가 될수 있으며 GTest같은 프레임워크를 통해 기능상의 테스트를 할 수 있다.

- 두번쨰로 컴파일러 빌드 테스트가 있따. 컴파이러가 코드를 빌드할 수 있어야 빌드 가능한 코드임을 증명할 수 있다.

 

테스트가 패스할 수 있는 최소한의 코드

테스트를 패스할수 있는 최소한의 코드만 작성하면 빠르고, 테스트가요구하는 기능을 충족할 수 있따.

아키텍처, exception, 호환성 같은 것들은 중요하지 않다.

 

리팩토링

이전까는 기능 개발을 했으니 이번에는 진짜 클린 코드를 만드는것

가독성을 높이고, 아키텍처를 고려하면 된다.

테스트를 패스하는 코드는 이미 작성했으니 테스트가 꺠지지 않는 선에서 코드를 개선하면 된다.

 

TDD의 이점중 하나는 테스트하기 쉬운 코드를 유도하게 되는 점인데 이를 통해 기느으이 모듈화나 인터페이스 분리와 같은 점을 빠르게 고려해서 짜게 되는 점이 이점이다. 테스트가 어려운코드는 대개 좋지 않은 디자인을 가진다.

 

종합하면 

개발 할 떄 테스트는 implementation test로써 '개발의 짙척도'를 나타내는 지표가도니다

이후 개발이 오나료되었을 떄는 regression test로써 코드의 안정성을 나타내는 지표가 된다.

 

TDD를 할떄 리팩토링 단계를 거침으로써 테스트하기 쉬운 코드를 짜야한다는 디자인 압박을 받게되는데 이압박을 통해 테스트 하기 좋은 코드를 작성하게되고 사용하기 쉬운 코드를 짜게 된다.

 

TDD를 통해 개발하면 거의 항상 100%의 coverage를 달성할 수 있다.