TDD vs Unit Test

TDD: Test Driven Development으로 테스트를 먼저 작성함으로써 즉각적인 피드백을 얻을 수 있고 프로그램의 품질을 높이고 안정성을 확보할 수 있는 방법.
Junit같은 도구를 이용한다 든가 CI서버라든가 리펙토링 테스트를 만들었을때 지속적으로 이점을 느낄수 있게 하는 도구가 많다. MAIN 메소드 이외에서 단위 테스트가 가능하다는 점에서 핵심로직을 분리해서 테스트 할 수 있다.단점있다. 단점: 개발속도가 느려진다. 테스트를 만들기 떄문에 속도가 줄어듭니다. 개발 Cost가 가하는 것뿐 다른 단점은 없다.

장점: 테스트를 먼저 작성하다보니 개발하고자 하는 의도가 명확해져 프로젝트 투입에 전체에 대한 그림을 다그리지 못했음에도 차근차근 이해하면서 개발할 수 있다.
생각지 못한 타이밍에 fail의 빨간 막대는 스트레스라기 보단 안심을 주는 장치이다.
그로 인해안심하고 진행할 수 있다.

Unit test: 단위테스트로Junit 같은 도구가 있다.

장점: 테스트케이스를 작성함으로써 영향을 끼치는 구조를 파악할 수 있다.
테스트 케이스들로 안심하고 리팩토링을 할 수 있점이 좋다.
개발과정 중 미리 문제를 파악할 수 있다.
테스트 자동화를 통해서 항상 딜리버리가 가능한 소프트웨어 제품을 만들 수 있다.
새로운 입력이 팀에 합류 했을때, 개발 스타일, 표준 ,컨벤션등을 공유하기에 좋다.
페어 프로그래밍할 때, 테스트케이스 작성하고 개발하는 역할 핑퐁을 통해서 개발을 페어로 중해서 진행할 수 있다.
TDD + Pair Programming 한다면, 테스트케이스 작성한 사람의 설계를 공유하면서 소스 개발까지 이어질 수있어 집중도가 높아진다.

단점: 시간이 많이 걸린다.
개발 cost가 많이 들기 떄문에 개발팀 전체가 규칙을 세우고 관심을 가져야 한다.

결론: TDD를 한다고 나쁜 냄새가 나는 코드나 구조를 만드는 것은 아니다.
테스트 한다는 것은 어렵다. 하지만 점진적으로 해나가다보면 적응할 수 있다.
junit 같은 도구를 사용하여 테스트를 먼저 작성함으로써 개발과 동시에 서비스 로직을 이해하는 방법이 TDD이다.