TDD

테스트 주도 개발 : 테스트가 개발을 이끌어 나간다.

구체적인 개념

테스트를 먼저 만들고 통과하기 위한 것을 짜는 것 즉 만드는 과정에서 테스트를 작성하고 그걸 통과하는 코드를 만들고 반복하면서 제대로 동작하는지에 대한 피드백을 적극적으로 받는 것

보통 테스트는 기능을 구현을 마치고 한다
하지만 이것의 순서를 바꾸는것이 TDD를 적용하는 것

언제 사용하면 좋은지?

1. 처음해보는 프로그램을 사용할때

• 자신에 대한 불확실성이 높은 경우

2. 고객의 요구조건이 바뀔 수 있는 프로젝트

• 외부적인 불확실성이 높은 경우

3. 개발하는 중에 코드를 많이 바꿔야 된다고 생각하는 경우
4. 내가 개발하고 나서 이 코드를 다른 사람이 유지보수를 할 경우

왜 사용하는지

결정과 피드백 사이의 갭(간격, 오차)를 줄이기 위해 사용

결정 : 이 방법으로 해야지, 이 부분에는 이걸 사용해야지라는 결정
피드백 : 프로그래밍을 하다보면 성공/실패/break 등 많은 피드백을 받는다

위 두개는 비슷하면서 둘 사이의 갭이 존재한다.
이 차이를 줄이기 위해 TDD를 사용한다.

효과

테스트 자체가 기본적으로 존재 소유가 되면서 효과를 나타낸다.

테스트 자체가 존재하므로 공유와 협력 이해에 많은 도움을 준다.

1. 남이 짠 코드를 쉽고 빠르게 이해 할 수 있다.
2. 테스트로 진행하기 때문에 기능을 확실히 알 수 있고 유지보수에 좋다.
3. 테스트 코드로 어떤 고민과 어떤 기능을 구현할지 나타내고 피드백 할 수 있다.
4. 왜? 이런 코드를 짜는지에 대해 확실하게 설명이 가능하다.
5. 결함이 줄어든다.

단점

1. 개발 시간이 늘어난다.
2. 반드시 툴(단위 테스트 프레임워크)을 써서 이렇게 해야된다