테스트코드를 작성해야 하는 이유
- 1) 잘 작동하는, 깔끔한 코드를 얻기 위해서(궁극적 목표)
- 테스트를 쉽게 하기 위해서는, 어플리케이션 코드를 테스트하기 쉽게 짜야됨
- 결국 테스트 코드를 짜기 위해 노력하다보면 코드가 깔끔해지게 됨
- 2) SW개발 시간의 단축
- 테스트 코드 작성 전 테스트 과정
1 2 3 4 5 6
1. 코드를 수정한다. 2. 서버를 동작시킨다. 3. 필요에 따라 테스트에 필요한 데이터를 DB에 입력한다. 4. 브라우저를 통해 우리의 서버에 접속하고, 테스트 대상 메소드를 동작시키는 요청을 한다. 5. 테스트를 마치고, DB의 데이터를 정리한다. 6. 이 과정을 반복한다.
- 한, 두번 정도는 이렇게 할수도 있겠지만, 알 수 없는 오류로 실패하는 경우 계속해서 테스트를 위해서 위 과정을 반복하게 되고 이는 매우 귀찮고 시간이 많이 소요됨
- 테스트 코드 작성 후 테스트 과정
1 2 3
1. 코드를 수정한다. 2. 테스트 코드를 실행한다.(테스트 코드를 이미 작성했다는 가정) 3. 결과를 확인한다.
- 테스트 코드를 작성한다면, 코드 수정 후 테스트 코드만 실행하면 됨
- 잘 작성된 코드는 테스트 코드를 통해서 실행이 성공됐는지 실패했는지 알 수 있기 때문에, 매우 많은 시간을 절약할 수 있음
- 테스트 코드 작성 전 테스트 과정
테스트 코드의 장점
- 서버를 실행하는 등의 시간을 절약할 수 있음
- 필요한 데이터를 미리 기입하고, 테스트가 끝나고 정리하는 등의 행동을 하지 않아도 됨
- 단위테스트의 경우 수십ms이기 때문에 테스트가 매우 빠름
- 문서로서의 역할이 가능
- 테스트 코드는, 개발자가 작성한 메소드가 어떻게 동작했으면, 어떤 결과를 반환했으면, 하는 것을 작성한 것이기 때문에 처음 코드를 보는 개발자들이 테스트 코드를 통해서, 코드의 동작을 좀 더 수월하게 이해할 수 있음
- 깔끔한 인터페이스를 얻어낼 수 있음
테스트 코드 작성 방법
- 예를 들어 Person클래스를 테스트한다고 가정
- 1) 테스트 대상 행위를 지정
- 예를 들어, Person객체에 hi()라는 메소드에 매개변수로 String타입의 name을 전달하여 호출하면
- 2) 기대하는 결과를 작성
- “hi name”을 반환해야 함
- 3) 두 문장을 결합해 테스트 코드로 작성
- 1) 테스트 대상 행위를 지정
테스트 코드를 작성함에 있어 어려운 것
- 수 많은 예외 상황에 대한 테스트 코드를 생각하는 것
- 테스트 커버리지를 높이는 것
- 테스트 코드의 가독성을 높이는 것
- FIRST원칙을 지키는 것
- 남들에게 도움이 되는 테스트 코드를 작성하는 것
테스트 코드 작성 TIP
- 1) given, when, then
- 테스트 코드 작성시, 많은 곳에서 추천하는 코딩 스타일로 어떤 값이 주어지고(given), 무엇을 했을때(when), 어떤 값을 원한다(then)을 나누어 직관적으로 볼 수 있기 때문에, 테스트 코드의 가독성이 향상됨
- 테스트 코드의 가독성이 중요한 또 다른 이유는, 테스트 코드가 문서로써의 역할을 하기 때문(테스트 코드로서 해당 메소드를 작성한 개발자가 어떤 의도로 만들었으며, 어떻게 동작하길 원하는지 알 수 있음)
- 2) 모든 Response에 대한 테스트를 진행
- api가(테스트 대상) 조금이라도 수정될 경우, 테스트코드가 실패하게 됨으로써, 항상 올바른 테스트 코드를 유지 할 수 있도록 도움
- api가(테스트 대상) 변경되면, 테스트 코드 역시 변경되어야 하는 것은 당연함
- 테스트 코드는 커버리지가 높을 수록 좋음, 테스트 코드는 정상적으로 작동하는 부분만을 테스트 하면 안됨, 테스트 코드는 실수나 오류를 발견하고 이를 줄이고 수정하기 위해 작성하는 것임
- 3) F.I.R.S.T 원칙
- Fast: 단위 테스트는 가능한 빠르게 실행되어야함, 실행함에 있어 너무 느려 테스트 실행을 꺼리게 되면 잘못된 단위테스트(하지만 Spring테스트시 @SpringBoot어노테이션을 사용한다면, 해당 애플리케이션의 모든 빈을 Ioc Container에 등록하고 테스트를 진행하기에 테스트가 느려질 수 밖에 없음)
- Independent: 단위테스트는 객체의 상태, 메소드, 이전 테스트 상태, 다른 메소드의 결과 등에 의존해서는 안됨. 따라서 단위 테스트는 어떠한 순서로 실행하더라도 성공해야 함
- Repeatable: 단위 테스트는 반복 가능해야함. DB에 의존하는 테스트는 테스트 수행 후 자동으로 롤백을 한다는 등의 별도 설정이 필요함
- Self-validating: 단위테스트는 자체검증이 가능해야함, 테스트를 개발자가 직접 수동으로 확인할 필요 없이, Assert문등에 의해 성공 여부가 결과로 나타나야 함
- Timely: 단위테스트를 통과하는 제품코드가 작성되기 바로전에 단위 테스트를 작성해야함, TDD를 하고 있다면 적용이 되지만 그렇지 않을수도 있음