이번 챕터의 주제는 테스트이다.
개발을 하고 1년이 지난 시점부터 굉장히 중요하다고 생각했던 주제이다.
기존에 작정한 UserDao는 데이터를 메인 메서드에서 데이터를 삽입해보고 정상적으로 들어갔는지 확인하는 방법이다.
- 웹을 통한 DAO 테스트 방법의 문제점
기존에 웹 프로그램에서 사용하는 테스트 방법은 모든 입출력 기능을 대충이라도 만들고 테스트 웹 애플리케이션을 배치한 뒤, 다시 데이터를 조회하는 URL을 만들어서 제대로 들어갔는지 확인하는 방법이라고 한다.
당연히 이러한 방법은 큰 문제들이 있다.
JSP, API까지 모두 만든 후에나 테스트가 가능하다는 단점이 가장 치명적이라고 한다. 또한, 버그가 발생하면 어느 부분에서 버그가 발생했는지 찾아야 한다고 한다.
- 작은 단위의 테스트
그렇기 때문에 테스트를 작은 단위로 나누고, 해당 대상에만 집중해서 테스트를 해야한다고 한다. 너무 많은 로직들이 모여있으면 정확한 원인을 찾기 힘들기 때문이다. 그렇기에 테스트의 관심이 다르다면 테스트 할 대상을 분리하고 집중해서 접근해야 한다. 그리고 이렇게 작은 단위테스트를 진행하는 이유는 개발자가 작성한 코드를 최대한 빠르게 검증받기 위해서다.
- 자동 수행 테스트 코드
기존에 사용하던 UserDaoTest는 테스트가 코드를 통해 자동으로 실행되고 있었다. 웹을 통해 데이터를 계속 넣어줄 필요가 없다는 말이다.
이렇게 하나하나 데이터를 넣으면서 테스트 하도록 만드는 것이 아니라, 코드를 통해서 자동으로 테스트가 진행되도록 만들어야 한다. 빠르고 지속적으로 기존에 만들었던 코드들을 검증해야 하기 때문이다.
- 지속적인 개선과 점진적인 개발을 위한 테스트
UserDaoTest는 처음에 무식하고 단순한 방법으로 정상적으로 동작하는 코드를 만들고, 지속적으로 테스트를 진행하며 코드를 검증했다.
그렇기에 코드를 리펙토링하면서 발생하는 에러들을 빠르게 검증 할 수 있었다. 이렇게 테스트를 이용하면 새로운 기능도 기대한 대로 동작하는지 확인할 수 있을 뿐 아니라, 기존에 만든 기능을 검증할 수 있는 것이다.
하지만 기존에 작성한 UserDaoTest가 완벽한 것은 아니다. 테스트는 자동으로 동작하지만, 검증은 데이터베이스와 로그를 확인해야 한다는 것이다. 그리고 main() 메서드라고 하더라도 매번 그것을 실행해야 하는 것이다. 이런 방법보다 더 편리하고 체계적인 테스트가 필요하다.
'백엔드 > 토비의 스프링' 카테고리의 다른 글
[토비의 스프링] 2.3 개발자를 위한 테스팅 프레임워크 JUnit (0) | 2025.05.19 |
---|---|
[토비의 스프링] 2.2 UserDaoTest 개선 (0) | 2025.05.18 |
[토비의 스프링] 1.8 XML을 이용한 설정 (1) | 2025.05.17 |
[토비의 스프링] 1.7 의존관계 주입(DI) (0) | 2025.05.15 |
[토비의 스프링] 1.6 싱글톤 레지스트리와 오브젝트 스코프 (1) | 2025.05.14 |