제 2장 테스트
저자는 스프링이 개발자에게 가장 중요한 가치가 무엇이냐고 질문한다면 객체지향과 테스트라고 대답할 것이라고 하였다. 객체지향은 C++과 자바를 배우면서 점차 익혀나가고. 있지만, 테스트의 중요성에 대해서는 점차 깨달아감에도 불구하고 쉽사리 접할 수 있는 기회가 없었다(핑계일까?). 이번 챕터를 통해서 단위 테스트와 통합 테스트의 중요성과 그 방법에 대해 알아갈 수 있었으면 좋겠다.
테스트의 유용성
테스트용 메소드(or 클래스)를 만들어 개발한 클래스의 메소드를 호출하고, 그 결과를 화면에 출력하여 그 값을 확인시켜 준다. 이 테스트용 메소드를 미리 만들어두었기 때문에, 기능이 추가되었어도 테스트를 통해 해당 클래스가 정상적으로 구동된다는 것을 알아낼 수 있었다.
테스트란 결국 내가 예상하고 의도했던 대로 코드가 정확히 동작하는지를 확인해서, 만든 코드를 확신할 수 있게 해주는 작업이다.
웹을 통한 DAO 테스트 방법의 문제점
(개인적으로 매.우 공감이 갔던 문장이다).
보통 웹 프로그램에서 사용하는 DAO를 테스트 하는 방법은 다음과 같다. DAO를 만든 뒤 바로 테스트 하지 않고(!!!!!), 서비스 계층, MVC 프레젠테이션 계층까지 포함한 모든 입출력 기능을 대충이라도 코드로 다 많든다. 이렇게 만들어진 테스트용 웹 애플리케이션을 서버에 배치한 뒤, 웹 화면을 띄워 폼을 열고(..), 값을 입력한 뒤 버튼을 눌러 등록해본다. 이를 위해서는 폼의 값을 받아서 파싱한 뒤에 User 오브젝트로 만들고 UserDao를 호출해주는 기능이 이미 만들어져 있어야 한다.
이러한 방식의 문제점은 DAO뿐만 아니라 서비스 클래스, 컨트롤러, JSP 뷰 등 모든 레이어의 기능을 다 만들고 나서야 테스트가 가능하다는 점이다. 더군다나 테스트 수행시 문제가 생긴다면 어느 부분에서 문제가 발생했는지 확인을 해야한다! 결국 DAO를 테스트하는 것이 아닌 전체 서비스를 테스트 하는 셈이 된다.
작은 단위의 테스트
테스트하고자 하는 대상이 명확하다면 그 대상에만 집중해서 테스트 하는 것이 바람직하다. DAO를 테스트 할 때는 웹 인터페이스나 그것을 위한 MVC 클래스, 서비스 오브젝트 등이 필요 없어야 한다. 이렇게 작은 단위의 코드에 대해 테스트를 수행한 것을 단위 테스트(unit test)라고 한다. 이 단위는 충분히 하나의 관심에 집중해서 효율적으로 테스트할 만한 범위의 단위라고 보면 된다.
개발자가 설계하고 만든 코드가 원래 의도한 대로 동작하는지를 개발자 스스로 빨리 확인하기 위해 단위 테스트를 수행하며, 확인의 대상과 조건이 간단하고 명확할수록 좋다. 또한, 단위 테스트는 코드가 바뀌지 않는다면 매번 실행할 때마다 동일한 테스트 결과를 얻을 수 있어야 한다(항상 일관성 있는 결과가 보장되어야함).
단위 테스트는 코드가 바뀌지 않는다면 매번 실행할 때마다 동일한 테스트 결과를 얻을 수 있어야 한다. 또한, 단위 테스트는 항상 일관성 있는 결과가 보장돼야 한다는 점을 잊어선 안된다.
JUnit 테스트 프레임워크
JUnit은 사실상 자바의 표준 테스팅 프레임워크라고 불릴 만큼 폭넓게 사용하고 있다. (프레임워크는 개발자가 만든 클레스에 대한 제어 권한을 넘겨받아 주도적으로 애플리케이션의 흐름을 제어한다.) JUnit 프레임워크를 이용하기 위해서 아래 두 가지 요건만 충족하면 된다.
- 테스트 클래스의 메소드가 public으로 선언될 것
- 메소드에 @Test라는 애노테이션을 사용할 것
JUnit은 특정한 테스트 메소드의 실행 순서를 보장해주지 않는다. 모든 테스트는 실행 순서에 상관없이 독립적으로 항상 동일한 결과를 낼 수 있도록 해야한다. 또한 JUnit에서는 각 테소트 메소드를 실행할 때마다 테스트 클래스의 오브젝트를 새로 만든다는 점을 기억해두어야 한다.
토비의 스프링 3.1을 토대로 작성하였으나, 개인적인 의견이 담겨있어 부정확한 내용이 작성되었을 수 있습니다. 코멘트로 많은 의견 부탁드립니다 :)
