토비의 스프링 스터디를 진행하며 작성한 글 입니다. 대부분 토비의 스프링을 참조하고 있습니다.
테스트란 무엇일까.
이전 팀에 있었을 때는 테스트를 작성하는 문화가 없었어서 테스트의 중요성을 잘 느끼진 못했다. 느끼지 못했다라기 보다는 느끼곤 있었지만 이게 테스트가 없어서 라는걸 알아채지 못했던 것 같다.
뭔가 개발 트렌드를 보면 TDD니 뭐니 하면서 테스트를 무조건 해야해!!! 라고 외치고 있었지만 정작 팀에서는 안하다보니 개발 시간을 더 잡아먹는 골치 아픈 프로세스 라고 막연히 생각했었다.
그런데 지금 팀에서는 뭐 아주 바쁠때는 테스트를 잠시 뒤로 미루긴 하지만 건너뛰진 않는다. 커버리지를 100%까지 채우긴 힘들지만 되도록 커버리지를 높이려고 노력하고 있다.
개발을 하면서 테스트를 작성하면서 늘어가는게 하나 있는데,
수정에 대한 자신감 !
수정을 안하면 좋겠지만 리팩토링이든 요건 변경이든 이런저런 이유로 이미 레거시가 되어버린 코드를 수정하게 되는데, 이젠 테스트만 돌리면 되니 안도감이 생긴다.
특히 다른 사람이 짠 코드와 연관된 부분을 수정할 때 이 쾌감을 느끼게 되는데, 이전에는 테스트를 안짰기에 하나하나 손테스트를 했지만 이제는 전체 테스트만 한 번 실행해보면 된다.
이 쾌감이란 !
2장 테스트 서문에서도 이 말을 하고 싶었던 것 같다.
만들어진 코드에 확신을 가질 수 있게 해주고 변화에 유연하게 대처할 수 있는 자신감을 주는 것이 테스트 !
라고 한다.
이제 본격적으로 스터디를 시작해보자.
2.1 1장에서 작성한 테스트 다시 보기
TestMain의 특징
웹을 통한 DAO 테스트 방법의 문제점
이 부분은 잘 공감이 가지 않았는데 예전에 쓰여진 책이라 그런가...
보통 웹 프로그램에서 사용하는 DAO 를 테스트하는 방법으로 서비스 계층, MVC 프레젠테이션 계층, DAO 를 대충이라도 모두 만들고 화면까지 띄워서 값을 입력하고 버튼을 누르고...를 예시로 들었는데.
단위 테스트에 익숙해져서인지 통합테스트가 아닌 이상에야 이런 식의 테스트가 보통의 테스트라는게 공감이 가지 않았다.
이런 식으로 코드를 작성하게 되면 당연히도 내가 테스트 하고 싶은 부분 외에 발을 걸치고 있는 코드들이 너무나 많아서 원하는걸 테스트 하기 쉽지 않다.
에러가 발생해도 뭐 때문인지 확인하기 어렵고, 성공해도 정말 문제가 없어서 성공한건지 알기 쉽지 않다.
작은 단위의 테스트
이런걸 단위 테스트라고 한다.
public class TestMain {
public static void main(String[] args) throws SQLException, ClassNotFoundException {
UserDao dao = new UserDao();
User user = new User();
user.setId("testId");
user.setName("테스트아이디");
user.setPassword("password");
dao.add(user);
System.out.println(user.getId() + " 등록 성공");
User user2 = dao.get(user.getId());
System.out.println(user2.getName());
System.out.println(user2.getPassword());
System.out.println(user2.getId() + " 조회 성공");
}
}기존에 작성했던 1장의 테스트 코드를 한 번 살펴보자.
위에서 말했던 모든 계층을 다 거치는 테스트랑은 거리가 멀어보인다. 간단히 작성하긴 했지만 DB에 값을 등록하고 조회해오는 DB 관련 기능만 딱 집어서 테스트를 하고 있다.
내가 테스트 하고 싶은 기능에만 집중해서 테스트 하는 것.
이렇게 한 가지 관심에 집중할 수 있게 작은 단위로 만들어진 테스트를 단위 테스트라고 한다. 관심사의 분리라는 객체지향적 특징이 여기에도 반영된건데 이렇게 관심사를 분리하면 다른 기능이 어떻게 구현되었든 현혹되지 않고 원하는 기능이 잘 만들어졌는지만 효율적으로 파악할 수 있다.
간혹 DB 가 사용된 테스트는 단위 테스트라고 할 수 없다고 하는 개발자들도 있다고 하는데, 완전히 통제할 수 있는 DB 리소스를 사용하고 있다면 단위 테스트라고 볼 수 있다. 위의 TestMain 에서는 매 테스트마다 기존에 생성된 DB 데이터를 지워줘야하는데, 이 부분은 우리가 통제할 수 있기 때문에 단위 테스트가 될 수 있는 것이다.
만약 우리가 DB 를 통제할 수 없다면, 예를 들어 DB 에 값이 저장되었고 다시 테스트를 하기 위해 이 값에 수정이 필요하다고 해보자. 하지만 이 리소스에 대한 통제 권한이 없어서 테스트 진행에 영향을 주게 된다면 이는 단위 테스트라고 부를 수 없다.
추가로 단위 테스트가 필요한 이유
단위 테스트 외에도 좀 더 긴 과정을 테스트 해야할 경우도 있을 것이다. 각각의 기능은 잘 작동해도 어떤 이유에선지 일련의 프로세스를 타면 안되는 경우도 많기 때문에 이런 테스트도 필요하다.
예를 들어 로그인 하고 특정 메뉴를 누르고 어떤 과정을 진행하고 DB 를 건드는 일련의 과정 같은걸 하나의 테스트로 진행할 수도 있다.
이때 만약 각각의 과정들을 단위 테스트로 작성해두었다면 중간에 어떤 에러가 발생해도 어디에서 문제가 발생했는지 보다 빠르게 확인할 수 있다.
그리고 개발자 입장에서도 자신이 설계해서 만든 코드가 자신의 의도대로 정상 작동하는지 빠르게 피드백을 받을 수 있다는 점에서도 단위 테스트는 필요하다. 그래서 단위 테스트를 개발자 테스트라고 부르기도 한다.
자동수행 테스트 코드
테스트는 자동으로 수행되도록 작성해야한다. 이것도 당연한 느낌이긴한데... 손으로 일일이 확인하는게 시간도 걸리고 정확성 면에서도 떨어지기 때문에 테스트를 작성하자는건데 자동으로 수행되도록 안짜면 말이 되나... 싶지만 일단 작성해본다.
손으로 테스트를 진행한다면 하나의 프로세스를 거치려고 해도 짧게는 몇초에서 길게는 몇 분까지 진행해야할 수도 있다. 게다가 테스트를 한 번만 하는 것도 아니고, 한 개만 하는 것도 아니니 이 지난한 과정을 지나치다가 실수가 일어날 수도 지칠 수도 있다.
하지만 자동으로 수행되도록 작성된다면 난 테스트 실행만 하면 되고 귀찮고 어렵고 지루한 과정은 컴퓨터가 대신해준다. 빠르고 정확한 결과물은 덤이다.
그리고 자주 반복할 수 있다는 것도 큰 장점이다. 내가 짠 코드가 레거시 코드들과 많은 연관관계가 있다면 이걸 손 테스트로 테스트하는건 아주 큰 문제가 될 수 있다.
하지만 우리에겐 자동 수행 테스트가 있으니 걱정하지 말자. 컴퓨터 시키면 된다.
지속적인 개선과 점진적인 개발을 위한 테스트
단위 테스트를 작성하고, 또 이 코드를 자동으로 수행되도록 작성했다.
이제 우린 수정에 대한 자신감을 얻었다 !
이 자신감으로 우리의 개발은 빨라질 것이고 시행착오는 적어질 것이며 연봉은 올라갈 것이다.
TestMain 의 문제점
당연하게도 지금의 TestMain에는 많은 문제가 존재한다.
일단 우린 테스트를 한다고는 했지만 그 결과를 우리 눈으로 직접 확인하고 있다.
그냥 프린트만 찍어서 어떤 결과가 나왔는지만 확인하고 있다.
이러면 안된다. 지금이야 한 두개지만 나중에 수십 수백개의 테스트를 돌리면 어떻게 일일이 이 결과를 확인하고 있나.
결과에 대한 확인까지 테스트가 자동으로 수행하게 해야한다.
실행이 번거롭다.
지금은 테스트를 실행하려면 TestMain의 main()을 직접 실행해줘야한다. 이것도 위의 이유와 마찬가지로 하나하나 언제 다 실행하고 있나.
테스트를 한 번에 실행할 수 있는 무언가가 필요하다.
다음 글에서 계속
[토프링] 2장 테스트 - 그 외 개념들
