단위 테스트
정의
테스트 가능한 가장 작은 소프트웨어를 실행하여 동작함을 확인한다. 큰 프로그램을 작은 단위로 쪼개서 해결하는 개념이다.
쓰는 이유와 방법
내 코드가 안전함을 증명하는 것이라고도 볼 수 있겠다. 프로그램을 최소한의 단위로 나누면 문제가 생길 가능성이 줄어드는 이점이 있다(분할 정복 개념과 비슷함). 또 메인메소드로 테스트를 만들면 클래스 크기가 커져 복잡도가 증가하고, 테스트가 실 서버에 같이 배포되며 테스트 결과를 사람이 수동으로 확인해야 한다.
그런데 내가 메소드를 잘못 작성해도 결과값은 제대로 나오는 경우가 있다. 가령 나누기 메소드(a+b)를 만들었는데 실수로 a 만 리턴되게 해서 1/1 결과에서 a만 리턴되었지만, 테스트에서는 통과가 될 수 있다.
따라서 테스트는 검증하고자 하는 로직이 무엇인지, 경계값은 무엇인지를 고민하는 과정이 중요하다. 실패하는 테스트를 작성하는 것도 방법이다. 이 기능이 어떠한 기능인지, 어떠한 상황에서 문제가 될 수 있을지를 고민해 보자(ex. 0으로 나누거나 -1로 나누면 어떻게 될까?).
그러나 경계값을 찾기란 쉽지 않다. 일반적으로 특이한 값들(0,1,Integer.MAX_VALUE)이나 특정 주제의 극단 값들(로또번호는 1과 45)을 생각해 보자. 즉 내가 검증하고자 하는 값의 끝단을 찾아보자
어느 선까지 나는 테스트를 할 것인가? 라는 기준을 세우는 것도 중요하다. 커버리지를 고민하던가, 투자 가능한 시간을 고민하던가 하는 방법이 있는데, 결론적으로는 내가 불안하지 않을 정도로 테스트 코드를 작성해야 한다.
생각 정리하기
- 내가 단위 테스트를 왜 작성할까?
내 경우는 프로그램을 웹 환경에서 실행시키지 않고도 내 코드가 안전한지 확인할 수 있기 때문이다.
- 내가 작성한 좋은 단위 테스트는 어떤 부분에서 좋은 단위 테스트일까?
이 부분은 단위 테스트 작성 경험을 늘리고 답해야 할 것 같다.
- 좋은 단위 테스트를 작성하기 위해 어떠한 시도를 해볼 수 있는가?
경계값(극단값)과 특이값에 대한 고려와 내가 어떤 로직을 검증해야 하는지를 생각하자.
내 질문
저는 메소드를 분리 하면서 private으로 선언한 메소드를 테스트를 위해 public으로 바꾸곤 했는데, 테스트를 위해 public을 선언했다는 점이 아쉬웠습니다. 이것도 선택의 영역일까요?
-> 테스트가 필요하다고 생각이 들면, 이것이 의존관계가 많다는 생각을 하고, 클래스를 분리할 생각을 해보자
