“실패한 테스트를 성공시키기 위한 목적이 아닌 코드는 만들지 않는다”

추가하고 싶은 기능을 테스트 코드로 먼저 표현한다.

TDD 개발 방법은 테스트를 먼저 만들어 테스트가 실패하는 것을 보고 나서 코드에 손을 대기 시작한다.

이전에 만든 getUserFailure()에는 만들고 싶은 조건, 행위, 결과에 대한 내용이 잘 표현되어 있다.

테스트 구성 요소

이는 기능설계, 구현, 테스트라는 일반적인 개발 흐름 중 기능설계의 일부에 해당합니다.

추가하고 싶은 기능을 일반 언어가 아닌 테스트 코드로 표현하는 방법입니다.

일반적인 개발 방법 vs 테스트 주도 개발

일반적인 개발 코드를 만들고 나서 시간이 많이 지나면 테스트를 만들기가 귀찮아 진다. 작성한 코드가 많기 때문에 무엇을 테스트해야 할지 막막해진다. 결국 테스트 작성은 자꾸 뒷전으로 밀려나거나 점점 성의 없는 테스트를 만들게 된다.


테스트 주도 개발 테스트 성공을 위한 코드만 만들기 때문에 테스트를 빼먹을 수 없다. 테스트와 애플리케이션 코드의 작성시간의 간격이 짧아 진다. 코드에 대한 피드백을 빠르게 받을 수 있다. 코드에 대한 확신을 얻어 가벼운 마음으로 다음 단계로 넘어갈 수가 있다. 자신감&여유

결론 진작에 충분한 테스트를 했었다면 쉽게 찾아냈을 것을 미루고 결국 커다란 삽질로 만들어버리는 어리석은 짓을 하지 말자

출처

토비의 스프링(책)

댓글남기기