[토비의 스프링] 테스트 (2장)

2.1 UserDaoTest 다시 보기

2.1.1 테스트의 유용성

UserDao에서 관심을 분리하고 기능을 확장할 때 테스트가 없었다면 불안했을 것이다.

머릿속으로 시뮬레이션을 돌려보는 방법은 100% 확신할 수 없기 때문에

테스트란 내가 예상하고 의도했던 대로 코드가 정확히 동작하는지 확신할 수 있게 해주는 작업이 필요하다.

2.1.2 UserDaoTest의 특징

웹을 통한 DAO 테스트 방법의 문제점

웹 화면을 통한 테스트는 가장 흔히 쓰이는 방법이지만 단점이 너무 많다.

테스트를 위해 사용되는 자원이 많기 때문에 DAO만 테스트하고 싶은데 다른 곳에서 문제가 발생할 수 있다.

작은 단위의 테스트

테스트 수행 과정을 간단히 하고 오류를 쉽게 찾을 수 있게 하기 위해서 작은 단위로 쪼개는 것이 중요하다.

관심사의 분리가 여기서도 적용되는 것이다.

작은 단위라는 범위가 모호할 수 있지만 단위는 작을 수록 즉, 간섭이 적을 수록 좋다.

 

UserDaoTest에서처럼 테스트를 위한 특정 상태로 만들 수 없다면 테스트로서의 가치는 없다.

다르게 표현하면 통제할 수 없는 외부 리소스에 의존한 테스트는 단위 테스트가 아니라고 볼 수 있다.

자동수행 테스트 코드

테스트는 자동으로 수행되도록 코드로 만들어지는 것이 중요하다.

웹 서버를 열고 여러 번 클릭하지 않고 단순히 실행하면 끝나게 말이다.

이런 자동수행 테스트 코드로 우리는 계속 반복해서 테스트할 수 있고 빠르게 확신을 얻을 수 있다.

지속적인 개선과 점진적인 개발을 위한 테스트

앞서 언급한 내용을 기반으로 테스트 코드를 작성하면 우리가 얻을 수 있는 이점은 다음과 같다.

• 작성한 코드에 대해서 신뢰할 수 있다.
• 오류를 쉽게 찾을 수 있다.
• 빠르게 여러번 테스트할 수 있어 지속적이고 점진적인 개선할 수 있다.

2.1.3 UserDaoTest의 문제점

수동 확인 작업의 번거로움

콘솔에 출력되는 값으로 확인되기에 책임은 결국 사람에게 있다.테스트 코드의 양이 방대하게 많아지면 실수를 할 수도 있고 복잡해서 불편할 수 밖에 없다.

실행 작업의 번거로움

아무리 간단하게 테스트를 짜도 매번 main()을 실행한다면 수고가 이만저만이 아니다.또, DAO가 수백 개가 된다면 엄청나게 큰 작업이 될 수 밖에 없다.

2.1 UserDaoTest 다시 보기

2.2.1 테스트 검증의 자동화

지금의 테스트는 에러가 발생하는 것에 대해서 쉽게 확인 가능하다. 하지만 별도의 확인 작업이 필요하다.

// before
System.out.println(user2.getName());
System.out.println(user2.getPassword());
System.out.println(user2.getId() + " 조회 성공");

// after
if (!user.getName().equals(user2.getName())) {
    System.out.println("테스트 실패 (name)");
} else if (!user.getPassword().equals(user2.getPassword())) {
    System.out.println("테스트 실패 (password)");
} else {
    System.out.println("조회 테스트 성공");
}

위와 같이 변경하면 다음과 같은 장점이 생긴다.

• 단순히 "테스트 성공" 메세지만 확인하면 된다.
• UserDao의 2가지 기능을 쉽게 확인할 수 있다.
• 언제든지 다시 확인할 수 있다. 프레임워크 자체가 변경되는 큰 변화가 있어도 쉽게 확인할 수 있다.

개발 과정에서, 또는 유지보수 하면서 기존 애플리케이션 코드를 수정할 때, 새로운 기술을 적용할 때 문제가 없는지 확인하기 위해서 스스로 테스트를 수행하고 빠르게 실행 가능한 테스트 코드를 만들어둬야 한다.

2.2.2 테스트의 효율적인 수행과 결과 관리

이제 main()은 테스트로서 필요한 기능을 모두 갖추었지만 한계가 존재한다.

한계를 극복하기 위해 다음 조건을 만족하는 테스트 지원 도구가 필요하다.

• 일정한 패턴을 가진 테스트를 만들 수 있어야 한다.
• 많은 테스트를 간단히 실행시킬 수 있어야 한다.
• 테스트 결과를 종합해서 볼 수 있어야 한다.
• 테스트를 실패한 곳을 빠르게 찾을 수 있어야 한다.

위 조건은 사용할 JUnit이라는 테스팅 프레임워크의 장점이다.

JUnit 테스트로 전환

1장에서 프레임워크의 기본 동작원리는 제어의 역전이라고 했다.

코드 동작의 흐름이 프레임워크가 가져간다. 다시 말해 오브젝트를 실행시키는 코드를 만들 필요가 없다.

테스트 메소드 전환

main()은 클래스 스스로를 엔트리 포인트로 만들어 프레임워크에 적합하지 않다.

JUnit 사용하기 위한 조건은 2가지가 존재한다.

• 메소드를 public으로 선언하기
• @Test 어노테이션 붙여주기

검증 코드 전환

if/else 문장을 JUnit이 제공하는 assertThat이라는 스태틱 메소드로 다음과 같이 변경할 수 있다.

// before
if (!user.getName().equals(user2.getName())) { ... };

// after
assertThat(user2.getName(), is(user.getName()));