테스트하고자 하는 대상이 명확하다면 그 대상에만 집중해서 테스트하는 것이 바람직하다. 한꺼번에 많은 것을 몰아서 테스트하면 수행 과정도 복잡해지고, 오류가 발생했을 때 정확한 원인을 찾기 힘들다.
이렇게 작은 단위의 코드에 대해 테스트를 수행한 것을 단위 테스트라고 한다. 단위의 범위가 정해진 것은 아니지만 충분히 하나의 관심에 집중해서 효율적으로 테스트할 만한 범위의 단위라고 보면 된다.
일반적으로 단위는 작을 수록 좋다. 단위를 넘어서는 다른 코드를 신경 쓰지 않고도 동작할 수 있으면 좋다. 그럼 DB와 함께 테스트하는 DaoTest, RepositoryTest는 단위 테스트가 아닌 것일까? 사용할 DB의 상태를 테스트가 통제하고 있다면 단위 테스트라고 해도 된다. 하지만 DB의 상태가 매번 달라지고 테스트가 DB를 통제하지 못한다면 단위 테스트로서의 가치가 없어진다. 그런 차원에서 통제할 수 없는 외부의 리소스에 의존하는 테스트는 단위 테스트가 아니라고 본다.
단위 테스트를 하는 이유는 개발자가 코드에 대한 빠른 피드백을 받기 위해서다. 코드의 동작을 서버와 DB를 모두 연결한 뒤 확인할 수 있고 그 때 버그가 발견된다면 디버깅하기 남감할 것이다.
만들고자 하는 기능의 내용을 담고 있으면서 만들어진 코드를 검증도 해줄 수 있도록 테스트 코드를 먼저 만들고, 테스트를 성공시키는 코드를 작성하는 방식의 개발 방법이 있다. 이를 테스트 주도 개발이라고 한다.
TDD는 아예 테스트를 먼저 만들고 테스트가 성공하도록 하는 코드만 작성하는 식으로 진행하기 때문에 테스트를 빼먹지 않고 꼼꼼하게 만들어낼 수 있다. 덕분에 테스트 코드와 프로덕션 코드의 작성 간격이 0에 가깝고 코드를 작성하면 바로바로 테스트를 실행해볼 수 있게 된다.
TDD에서는 테스트 코드 작성과 프로덕션 코드 작성의 주기를 가능한 짧게 가져가는 것을 권장한다. 테스트를 반나절 만들고 프로덕션 코드도 반나절 만드는 방법은 좋지 않다.
TDD를 하면 자연스럽게 단위 테스트를 만들 수 있다.