자바와 JUnit을 활용한 단위테스트_05
5장. 좋은 테스트의 FIRST 속성.
단위 테스트를 주의 깊게 사용했을 때 많은 이점을 얻을 수 있다.
하지만 테스트 또한 유지 보수해야 하는 또 다른 코드이다.
테스트를 빛나게 하고 값어치를 하는 테스트를 만드는 데 도움을 주는 핵심 개념과 전술에 대해 알아보도록 한다.
"FIRST"의 원리. F는 fast, I는 isolated, R은 repeatable, S는 Self-validating, T는 timely.
Fast: 빠르다.
빠른 테스트는 코드만 실행하며(로컬에 있는 로직 코드만 실행함) 소요 시간은 수 밀리초 수준이다.
느린 테스트는 데이터베이스, 네트워크 호출처럼 외부 자원을 다루는 코드를 호출하고 수십, 수백 밀리 초가 걸리기도 한다.
물론 시스템이 커지면 단위 테스트도 실행하는데 오래 걸리는 것이 당연하다. 테스트를 빠르게 유지하자!
제일 먼저 느린 테스트에 대한 의존성을 줄여야 한다.
모든 테스트 코드가 데이터베이스를 호출한다면 전체 테스트 또한 느릴 것이다.
예를 들어 질문을 얻기 위해 컨트롤러에 질의하기보다는 먼저 질문을 가져오고 그 텍스트를 responseByQuestion() 메서드의 인수로 넘긴다.
대답에 대한 질문 ID와 질문 내용의 맵을 생성하는 questionText() 메서드를 생성한다.
responseByQuestion() 메서드에 질문 ID와 내용으로 매핑하는 변수를 추가하는데 이 변수는 convertHistogramIdsToText()에 넘겨질 것이다.
이 테스트는 responseByQuestion(), convertHistogramIdsToText(), incrementHistogram() 메서드에 있는 로직을 포함한다.
세 메서드의 로직으로 조합하여 테스트를 작성하게 되면 손쉽게 다수의 테스트를 가지게 되고,
더 많은 로직을 커버하는 소수의 빠른 테스트는 데이터베이스 호출에 의존하는 단일 테스트보다 수월하게 실행될 것이다.
Isolated: 고립시킨다.
좋은 단위 테스트는 다른 단위 테스트에 의존하지 않는다.
여러 테스트가 데이터를 재사용하는 방식으로 순서를 조작하여 전체 테스트의 실행 속도를 높일 순 있지만,
이렇게 하면 의존성의 악순환만 동시에 발생할 수 있다.
일이 잘못되면 실패했을 때 앞선 이벤트의 긴 사슬을 따라 무엇이 원인인지 알아내느라 긴 시간을 소모할 수 있다.
따라서!! 테스트 코드는 어떤 순서나 시간에 관계없이 실행할 수 있어야 한다.
각 테스트가 작은 양의 동작에만 집중하면 테스트 코드를 집중적이고 독립적으로 유지하기 쉬워진다.
Repeatable: 좋은 테스트는 반복 가능해야 한다.
반복 가능한 테스트는 실행할 때마다 결과가 같아야 한다.
따라서 반복 가능한 테스트를 만들려면 직접 통제할 수 없는 외부 환경에 있는 항목들과 격리시켜야 한다.
그러나 시간을 다뤄야 하는 것과 같이 불가피하게 통제할 수 없는 요소와 상호작용해야 한다면,
테스트 코드는 반복 가능한 테스트를 힘들게 하는 불편한 요소를 어떻게든 다루게 된다.
이때는 테스트 대상 코드의 나머지를 격리하고 시간 변화에 독립성을 유지하는 방법으로 목 객체를 사용할 수 있다고 한다.
목 객체에 대해서는 추후에....
Self-validating: 스스로 검증 가능하다.
테스트는 기대하는 것이 무엇인지 단언하지 않으면 테스트가 아니다.
단위 테스트는 시간을 소모하기보다는 절약한다.
또한 테스트는 스스로 검증 가능할 뿐만 아니라 준비할 수도 있어야 한다.
테스트에 필요한 어떤 설정 단계든 자동화하자.
이클립스나 인텔리제이를 사용한다면 Infinitest 같은 도구도 존재하고,
좀 더 큰 규모의 경우 젠킨스나 TeamCity 같은 CI(지속적 통합) 도구를 사용할 수도 있다.
여기서 CI 도구는 소수 저장소를 관찰하여 변화를 감지하면 빌드와 테스트 절차를 시작하는 도구라 할 수 있다.
용어 하나더! CD(지속적 배포)란,
CI에서 빌드하고 테스트한 결과가 배포 단계에서 release 할 준비 단계를 거치고 문제가 없는지 검증한다.
이후 문제가 없다고 판단되면 수동적으로 진행하는 것 또한 CD의 의미라 할 수 있다.
CI/CD에 대해 더 궁금하다면 내기준 추천 키워드인 "GitLab CI/CD"로 검색해서 도큐먼트 찾아보기.
Timely: 적시에 사용한다.
사실상 언제라도 단위 테스트를 작성할 수 있다.
가능하면 적절한 순간에 단위 테스트에 집중하는 것이 낫다.
많은 테스트에 중독된 갭발 팀의 단위 테스트에 대한 관한 지침은 엄격하고,
어떤 팀에서는 충분한 테스트가 없음에도 자동화된 도구로 단위 테스트를 사용하기도 한다.
단위 테스트를 더 많이 할수록 테스트 대상 코드가 줄어들고 두 번째, 세 번째... 코드를 넣었을 때 테스트 효과가 즉시 나타난다.
작은 규모의 코딩 테스트 주기로 발전한다면 그다음에는 테스트 다음 코드의 단계를 고려해보자.