단위테스트의 단위는 정하기 나름이다.

• 사용자 관리 기능 전체를 하나의 단위로 볼 수도 있고
• 하나의 클래스나 하나의 메서드를 단위로 볼 수도 있다.

중요한 것은 하나의 단위에 초점을 맞춘 테스트라는 점

⇒ 단위 테스트라는 용어를 사용할 때 의미를 명혹히 할 필요가 있다.

단위 테스트

테스트 대상 클래스를 목 오브젝트 등의 테스트 대역을 이용해 의존 오브젝트나 외부의 리소스를 사용하지 않도록 고립시켜서 테스트하는 것. ex. upgradeLevels()

통합테스트

두 개 이상의 성격이나 계층이 다른 오브젝트가 연동하도록 만들어 테스트하거나, 도는 외부의 DB나 파일, 서비스 등의 리소스가 참여하는 테스트

• 두 개 이상의 단위가 결합해 동작하면서 테스트가 수행되는 것이라 보면 된다. ex. 스프링의 스프링 컨텍스트 프레임워크를 이용해 컨텍스트에서 생성되고 DI 된 오브젝트를 테스트하는 것도 통합테스트

단위 테스트와 통합 테스트 중 어떤 방법을 쓸지 정할 때 가이드라인.

1. 항상 단위 테스트를 먼저 고려한다.

2. 고립된 테스트를 만든다.

   • 하나의 클래스나 성격과 목적이 같은 긴밀한 클래스 몇개를 모아서 외부와 의존 관계를 모두 차단
   • 필요에 따라 스텁이나 목 오브젝트 등의 테스트 대역을 이용

   <aside> 📌

   단위 테스트는 테스트 작성도 간단하고 실행 속도도 빠르며 테스트 대상 외의 코드나 환경으로부터 테스트 결과에 영향을 받지 않기에 가장 빠른 시간에 효과적인 테스트를 작성하기에 유리하다.

   </aside>

3. 외부 리소스를 사용해야만 가능한 테스트는 통합 테스트로 만든다.

4. 단위 테스트로 만들기가 어려운 경우, ex. DAO

   • DAO 는 그 자체로 로직을 담고 있기보다 DB 를 통해 로직을 수행하는 인터페이스와 같은 역할
   • SQL 을 JDBC 를 통해 실행되는 코드만으로 고립된 테스트 작성이 어렵다.
     • 작성해도 가치가 없는 경우가 대부분
   • 따라서 DAO는 DB 까지 연동하는 테스트로 만드는 편이 효과적

   <aside> 📌

   DB를 사용하는 테스트는 DB 에 테스트 데이터를 준비하고, DB 에 직접 확인을 하는 등의 부가적인 작업이 필요하다.

   </aside>

5. DAO 테스트는 DB 라는 외부 리소스를 사용하기 때문에 통합 테스트로 분류된다.

   • but! 코드에서 보자면 하나의 기능 단위를 테스트하기도 하다.
   • DAO 를 테스트를 통해 충분히 검증해두면 DAO 를 이용하는 코드는 DAO 역할을 스텁이나 목 오브젝트로 대체해 테스트할 수 있다.
     • 이후에 실제 DAO 와 연동하고 바르게 동작하리라 확신할 수 있다.
   • 충분한 단위 테스트를 거친다면 통합 테스트에서 오류가 발생할 확률도 줄어들고 발생해더 쉽게 처리 가능

6. 여러개의 단위가 의존관계를 가지고 동작할 때를 위한 통합 테스트는 필요하다.

   • 단위 테스트를 충분히 거쳤다면 통합 테스트의 부담은 상대적으로 줄어든다.

7. 단위테스트를 만들기 너무 복잡한 코드는 처음부터 통합 테스트를 고려해본다.

   • 이 때도 통합 테스트에 참여하는 코드 중 가능한 많은 부분을 미리 단위 테스트로 검증해두는 게 유리하다.