테스트
테스트란 내가 예상하고 의도했던 대로 코드가 정확히 동작하는지를 확인해서, 만든 코드를 확신할 수 있게 해주는 작업이다. 최종적으로 테스트가 성공하면 모든 결함이 제거됐다는 확신을 얻을 수 있다.
웹을 통한 DAO테스트 방법의 문제
DAO뿐만 아니라 서비스 클래스, 컨트롤러, JSP 뷰 등 모든 레이어의 기능을 다 만들고 나서야 테스트가 가능하다는 점이 가장 큰 문제이다.
작은 단위의 테스트
테스트는 가능하면 작은 단위로 쪼개서 집중해서 할 수 있어야 한다. 관심사의 분리라는 원리가 여기에도 적용된다. 이렇게 작은 단위의 코드에 대해 테스트를 수행한 것을 단위 테스트 라고 한다.
자동 수행 테스트
단위 테스트가 필요한 이유는 개발자가 스스로 빨리 확인받기 위해서이다. 그렇게 해기 위해서는 수작업을 거치는 방법을 사용하기보다는 코드로 만들어져서 자동으로 수행될 수 있어야 한다.
1장에서의 UserDaoTest의 문제점
-
수동 확인 작업의 번거로움
print를 통해서 비교하고 확인하는 방식은 발견하지 못하고 넘어가는 실수를 할 가능성이 있다. -
실행 작업의 번거로움
각 테스트마다 main()을 통해 동작하기 때문에 테스트 코드가 수백 개가 된다면 main()을 수백 번 실행해야하는 수고가 필요하다.
JUnit 테스트
테스트 결과의 일관성
테스트를 실행하기 전에 DB에 테이블 데이터를 모두 삭제해주어야 한다. 테스트를 아무리 여러 번 반복해서 실행하더라도 항상 동일한 결과를 얻을 수 있도록. -> 내가 최근에 고민하던 문제이다. 웹에서 테스트를 하게 되면 자동적으로 DB에 데이터가 쌓이는데 이렇게 되면 Junit을 통한 테스트의 문제가 생긴다. 그래서 웹으로 테스트를 하더라도 DB를 깨끗하게 지우고 Junit도 DB에 아무것도 없다고 생각하고 코드를 작성해야한다.
포괄적인 테스트
테스트를 안만드는 것도 위험한 일이지만, 성의없이 테스트를 만드는 바람에 문제가 있는 코드인데도 테스트가 성공하게 만드는 건 더 위험하다. -> 문제가 있는지 없는지 모르는 것도 위험하지만, 문제가 있지만 없다고 확신하는 것 또한 위험하다.
테스트의 결과가 테스트 실행 순서에 영향을 받는 다면 테스트를 잘못 만든 것이다. JUnit은 각 테스트가 서로 용향을 주지 않고 독립적으로 실행됨을 확실히 보장해주기 위해 새로운 오브젝트를 만든다.
테스트를 직접 만들 때 자주 하는 실수는 성공하는 테스트만 골라서 만드는 것. 부정적인 케이스를 먼저 만드는 습관을 들이는게 좋다. 예외적인 상황을 빠뜨리지 않는 꼼꼼한 개발이 가능하다.
테스트가 이끄는 개발
테스트할 코드를 만들기 전에 테스트 코드부터 만드는 것. 이 방식은 추가하고 싶은 기능을 테스트코드로 표현하는 느낌으로 사용한다. 이렇게 테스트 코드를 먼저 만들고, 테스트를 성공하게 해주는 코드를 작성하는 방식의 개발방법을 테스트 주도 개발(TDD)이라고 한다.
TDD에서는 테스트 작성하고 이를 성공시키는 코드를 만드는 작업의 주기를 가능한 한 짧게 가져가도록 권장한다.
DI와 테스트
DI를 받을 때 인터페이스를 사용해하는 것이 좋은 이유가 무엇일까? -> 이 부분도 고민하던 문제인데, 굳이 하나의 클래스만 사용할 건데 굳이 왜 인터페이스를 사용하여야 하는지 이유를 몰랐다.
- 첫째, 개발에서 절대로 바뀌지 않는 것은 없기 때문이다.
- 둘째, 다른 차원의 서비스 기능을 도입할 수 있기 때문이다.
- 셋째, 테스트는 가능한 한 작은 단위의 대상에 국한해야하기 때문이다.
이 책에서 이야기한 세가지의 이유중에서 제일 와닿은 설명은 절대로 바뀌지 않는 것은 없기 때문이다. 객체지향에서는 변경에 대해서 닫혀있어야 하는데, 만일 테스트할 구첵적인 클래스가 바뀌면 테스트코드도 바꾸어야 한다. 이는 원칙에도 안맞지만, 매우 귀찮은 일인 것도 사실이다.
학습 테스트
자신이 만들지 않은 프레임워크나 다른 개발팀에서 만들어서 제공한 라이브러리 등에 대해서 학습하기 위헤 테스트를 작성하는 것을 학습 테스트라고 한다.
학습테스트 장점
- 다양한 조건에 따른 기능을 손쉽게 확인해볼 수 있다.
- 학습 테스트 코드를 개발중에 참고할 수 있다.
- 프레임워크를 업그레이드할 때 호환성을 검증을 도와준다.
- 테스트 작성에 대해 좋은 훈련이 된다.
- 새로운 기술을 공부하는 과정이 코드 작성으로 즐거워 진다.
정리
- 작은 단위의 코드에 대해 테스트를 수행한 것을 단위 테스트
- 웹으로 테스트를 하더라도 DB를 깨끗하게 지우고 Junit도 DB에 아무것도 없다고 생각하고 코드를 작성해야한다.
- 문제가 있는지 없는지 모르는 것도 위험하지만, 문제가 있지만 없다고 확신하는 것 또한 위험하다. => 테스트 코드를 꼼꼼히 작성해야하는 이유
- 테스트를 직접 만들 때 자주 하는 실수는 성공하는 테스트만 골라서 만드는 것.
- 테스트 주도 개발(TDD)은 테스트할 코드를 만들기 전에 테스트 코드부터 만드는 것
