2장) 2.3 개발자를 위한 테스팅 프레임워크 JUnit

2장 테스트

2.3 개발자를 위한 테스팅 프레임워크 JUnit

• 스프링 프레임워크도 JUnit을 이용해 테스트를 통해 개발됨

  • 테스트 없이는 스프링도 의미 없음

• 빌드 툴

  • ANT, Maven, Gradle과 같은 빌드 툴과 스크립트를 사용한다면 ~> 빌드 툴에서 제공하는 Junit 플러그인이나 태스크를 이용해 JUnit 테스트를 실행

• 테스트 결과의 일관성

  • DB 서버가 다운되거나 네트워크 장애 등 외부 상태에 따라 테스트가 성공하기도 실패하기도 한다면 좋지 못한 테스트이다.
  • 또한, 테스트를 마친 후, 수행하기 이전으로 DB의 상태를 돌려야 함
  • 동일한 결과를 보장하는 테스트
    • 예시의 테스트를 시작하기 전에 기존의 데이터를 항상 지우고 시작하게 설정하면, 해당 add를 하는 메소드에서, 항상 같은 결과 값을 리턴한다.

• 포괄적인 테스트

  • getCount 테스트를 조금 더 꼼꼼하게 수정하자
    • 3명의 각기 다른 유저 오브젝트를 생성해두고, deleteAll을 수행한 다음, 각 유저 오브젝트를 add 메소드로 등록하면서 getCount가 제대로 동작하는지 확인

• 예외 조건 테스트

  • get() 테스트의 경우, 메소드에 전달된 id 값에 해당하는 사용자 정보가 없는 경우, 예외를 던지는 것이 바람직하다.

    • @Test Annotation에 expected를 추가해두면, 보통의 테스트와 반대로 정상적인 테스트는 실패하고, expected에서 지정한 예외가 던져지면 테스트가 성공한다.

    • @Test(expected=EmptyResultDataAccessException.class)
      public void getUserFailure() throws SQLException {
          //...
      }

• 테스트가 이끄는 개발

  • 기능 설계를 위한 테스트
    • Given, When, Then으로 구성하여 개발 흐름의 기능설계의 일부분을 테스트 코드가 담당

• 테스트 주도 개발 (TDD)

  • 테스트 코드를 먼저 작성 ~> 테스트를 성공하게 해주는 코드를 작성하는 개발 방식
  • 테스트를 작성하는 시간과 Application 코드를 작성하는 시간의 간격이 짧아짐
    • 이 주기를 최대한 짧게 가져가도록 권장
  • 머릿속에서 복잡하게 진행하던 작업을 실제 코드로 끄집어 내놓으면 TDD
  • 테스트 없이 한번에 너무 많은 코드를 작성하는 것을 지양한다.
  • 테스트를 만들고 자주 실행하면 개발이 지연되지 않을까 염려할 수 있겠지만, 그렇지 않다.
    • 테스트 덕분에 오류를 빨리 잡아낼 수 있어서 전체 개발 속도는 오히려 빨라짐
    • 서버에 올려서 테스트하고 코드 수정하는 과정이 생략되어 속도가 빨라짐

• 테스트 코드 개선

  • 리팩토링 대상은 애플리케이션 코드만이 아닌 테스트 코드도 포함된다.
    • 내부 구조 및 설계를 개선해서 좀 더 깔끔하고 이해하기 쉬우며, 변경이 용이한 코드를 만들 필요가 있음
  • getBean을 통해 context에서 bean을 주입받는 코드의 경우, 메소드 추출 리팩토링 방법 대신, JUnit의 @Before를 이용해서 편하게 관리할 수 있다.

• JUnit 테스트 수행 방식

  1. 테스트 클래스에서 @Test가 붙은 public이고 void형이며 파라미터가 없는 테스트 메소드를 모두 찾는다.
  2. 테스트 클래스의 오브젝트를 하나 만든다.
  3. @Before가 붙은 메소드가 있으면 실행
  4. @Test가 붙은 메소드 하나를 호출, 테스트 결과 저장
  5. @After 붙은 메소드 실행
  6. 나머지 테스트 메소드에 대해 2~5 반복
  7. 모든 테스트 결과를 종합해서 리턴
  • 실제 과정은 더욱 복잡하지만, 간략하게 정리하면 위의 7단계를 거침
  • 테스트 메소드를 실행할 때마다 새로운 오브젝트를 만드는 이유는, 각 테스트가 서로 영향을 주지 않고 독립적으로 실행됨을 확실히 보장해주기 위함
    • 따라서, 모든 테스트는 실행 순서에 상관 없이 독립적으로 항상 동일한 결과를 낼 수 있도록 해야함

• 픽스처(Fixture)

  • 테스트를 수행하는 데 필요한 정보나 오브젝트
    • 일반적으로 여러 테스트에서 반복적으로 사용되기 때문에, @Before 메소드를 이용해 생성해두면 편리하다
    • 대표적인 예시는 dao

• 현재 버전에서는 Before는 deprecated ~> BeforeEach