p.145 ~ 183
테스트의 유용성
테스트란 결국 내가 예상하고 의도했던 대로 코드가 정확히 동작하는지를 확인해서, 만든 코드를 확신할 수 있게 해주는 작업이다. 또한 테스트의 결과가 원하는 대로 나오지 않는 경우에는 코드나 설계에 결함이 있음을 알 수 있다. 이를 통해 코드의 결함을 제거해가는 작업, 일명 디버깅을 거치게 되고, 결국 최종적으로 테스트가 성공하면 모든 결함이 제거됐다는 확신을 얻을 수 있따.
웹 화면을 통해 값을 입력하고, 기능을 수행하고, 결과를 확인하는 방법은 가장 흔히 쓰이는 방법이지만, DAO에 대한 테스트로서는 단점이 너무 많다. DAO뿐만 아니라 서비스 클래스, 컨트롤러, JSP 뷰 등 모든 레이어 기능을 다 만들고 나서야 테스트가 가능하다는 점이 가장 큰 문제이다. 테스트를 하는 중에 에러가 나거나 테스트가 실패했다면, 과연 어디에서 문제가 발생했는지를 찾아내야 하는 수고도 필요하다.
작은 단위의 테스트
작은 단위의 코드에 대해 테스트를 수행하는 것을 단위 테스트(unit test)라고 한다.
단위는 충분히 하나의 관심에 집중해서 효율적으로 테스트할 만한 범위의 단위라고 보면 되고, 일반적으로 단위는 작을수록 좋다.
테스트 중에 DB가 사용되면 단위 테스트가 아니라고 하기도 하는데,
DB의 상태가 매번 달라지고, 테스트를 위해 DB를 특정 상태로 만들어줄 수 없다면 단위 테스트로서 가치가 없어지기 때문에, 그런 차원에서는 통제할 수 없는 외부의 리소스에 의존하는 테스트는 단위 테스트가 아니라고 보기도 하는 것이다.
단위 테스트를 하는 이유는 개발자가 설계하고 만든 코드가 원래 의도한 대로 동작하는지를 개발자 스스로 빨리 확인받기 위해서다.
JUnit
Junit은 프레임워크로, 메인 메소드가 필요하지 않다.
JUnit 의 조건
- 메소드가 public으로 선언되어야 한다.
(접근제어자는 생략하더라도, public으로 생성되는 것으로 알고 있음.)
- 메소드에 @Test라는 애노테이션을 붙여주어야 한다.
테스트 메소드에서 예외 상황이 발생할 수 있는 경우에는 애노테이션에 excepted 엘리먼트를 명시해주면 된다.
@Test(expected = EmptyResultAccessException.class)
public void getUserFailure() throws SQLException {
~~~
}포괄적인 테스트
스프링의 창시자인 로드 존슨은 "항상 네거티브 테스트를 먼저 만들라"라는 조언을 했다고 한다.
테스트를 작성할 때는 부정적인 케이스를 먼저 만드는 습관을 들이는 것이 좋다.
존재하는 정보에 대한 확인을 하는 테스트도 좋지만, 존재하지 않는 객체에 대해서는 어떻게 반응할지를 먼저 결정하고, 이를 확인할 수 있는 테스트를 먼저 만들려고 한다면 예외적인 상황을 빠뜨리지 않는 꼼꼼한 개발이 가능하다.
TDD
TDD에서는 테스트 작성하고 이를 성공시키는 코드를 만드는 작업의 주기를 가능한 짧게 가져가도록 권장한다.
Annotation
@Before (=@BeforeEach)
모든 테스트 메소드가 실행되기 전에 각각 실행되는 메소드
@BeforeAll
테스트 클래스가 실행되었을 때 한 번 실행되는 메소드
@After (=@AfterEach)
모든 테스트 메소드가 실행된 후 각각 실행되는 메소드
@AfterAll
테스트 클래스가 끝나기 전에 마지막으로 한 번 실행되는 메소드
