TDD란?
TDD란 Test Driven Development의 약자로,테스트 케이스를 먼저 작성 후, 최소한의 코드를 작성하고, 코드를 리팩토링을 하는 것을 하나의 개발 사이클로 잡고 이를 매우 짧고 자주 반복하는 개발 프로세스를 의미한다.
프로세스
기본적으로 RGR(Red-Green-Refeactoring)형태의 프로세스를 따른다.
Red:테스트 코드를 작성하는 단계.
Green: Red에서 짠 테스트 코드를 성공시키기 위해, 프로덕션 코드를 수정하는 단계
Refactor:테스트 코드가 성공한 프로덕션 코드를 보다 나은 품질의 코드로 리팩토링 하는 과정
위의 글을 참고하면 간접적으로 tdd가 무엇인지 참고 할 수 있다.
tdd에서 의식해야할 점
기존에 tdd를 이미 한번 공부를 하고, 이번에 다시 봤는데, 그 전에 공부 할 때는 tdd를 사용할 때 의식해야할 점에 대해서 몰랐는데, 그러한 것들이 있다는 것을 알게되었다.
일단 간단하고 해보기 쉬운 것을 시도한다.
일반적으로 간단한 코드들이 모여서 복잡한 기능을 만들어낸다. 간단하고 짧은 코드의 tdd를 먼저 시도해봄으로써, 복잡한 코드를 짤 때 더욱 안정적인 tdd와 기능을 구현할 수 있다.
또한 이를 바탕으로 tdd의 원래 목적인 짧은 개발 프로세스를 구현할 수 있다.
실패하는 테스트를 통과하기 위해서는 최소한의 코드를 작성해야 한다.
이 이유도 짧은 개발 프로세스를 구현하기 위해서 라고 생각이 든다. 그래야 실수할 가능성이 줄어들고, 안정적인 코드를 작성할 수 있으니까.
테스트를 점점 구체화할수록 프로덕션 코드는 점점 범용적으로 된다. (커버 가능한 케이스가 점점 많아진다.)
예를 들어서 더하기 기능에 대해서 1+1=2를 테스트 하는 코드를 처음에 만들었다고 해보자. 이 코드의 함수에서는 단순히 return 2를 통해서 가장 빠르게 tdd를 구현할 수 있다. 이 이후 다시 2+2=4라는 테스트 코드를 작성했다고 해보자.
이 때 기존에 작성한 로직이 단순히 return 2이므로 당연하게도 2+2=4의 테스트 코드는 돌아가지 않는다. 이를 위해서
public int plus(int a,int b){
return a+b;
} 로 프로덕션 코드가 훨씬 범용적이고, 작성해야한다.
범용적인 코드가 되었으므로, 더욱 많은 케이스를 커버가능할 것이다.
실패하는 테스트가 있을 때만 프로덕션 코드를 작성한다.
테스트가 실패하는 상황에서만 프로덕션 코드를 작성해야한다는 것으로, 불필요한 코드를 작성하지 말라는 의미이다.
이를 통해서 불필요한 시간을 줄일 수 있어서, 짧은 개발 프로세스를 유지할 수 있다.
실패를 나타내는 데 충분한 정도의 테스트만 작성한다
테스트 코드가 너무 많아지는 것을 방지하라는 의미이다.
의의
전반적으로 짧은 개발 프로세스, 불필요한 코드 방지를 위해서, 생각해야 할 것이다. 이를 통해서 여러번의 프로세스를 거쳐서 훨씬 안정적인 코드를 짜는데 도움을 두고, 결합이 느슨한 시스템을 점진적으로 만들 수 있다.
TDD가 진짜 필요한 기능인지? 어플리케이션인지?에 대해서 생각해보는게 중요한게 생각보다 귀찮기 때문이다.
실제로 직관적으로 작성할 수 있는 코드는 테스트 코드를 먼저 작성하기보다, 프로덕션 코드를 먼저 작성하는게 나을 수도 있다는 생각을 한다. 
