JUnit In Action 4장 소프트웨어 테스트 원칙
다재 다능한 개발자가 되려면, 단위 테스트를 기능 테스트 , 통합 테스트 등의 다른 테스트와 구분해서 이해하고 있어야한다.
단위테스트가 꼭 필요한 이유를 이해하고 나면 어디까지 테스트해야하는지 알아야한다.
테스트 자체가 목적이 아니기때문에....
우선 이번장으로 테스트의 필요성과, 소프트웨어 종류, 단위테스트의 종류를 알아볼 것이다.
1. 단위 테스트가 필요한 이유
단위 테스트의 주 목적은
1. 애플리케이션이 잘 돌아가는 지 증명
2. 버기를 조기에 잡아내는것
허나 위 같은 경우 기능 테스트도 해당 사항이다
하지만 단위테스트는 보다 강력한 애플리케이션 동작 여부 확인 그 이상을 제공한다.
- 기능 테스트 보다 훨씬 높은 테스트 커버리지 달성
- 팀 생산성 향상
- 회귀 테스트 수행하고 디버깅 필요성 줄어든다
- 리팩터링과 코드 수정시 올바로 하고 있다는 확신
- 구현 품질 향상
- 기대하는 행위 문서화
- 코드 커버리지등 각종 측정 가능
기능 테스트보다 훨씬 높은 테스트 커버리지 달성
기능 테스트는 애플리케이션 코드의 약 70%를 커버할 수 있다.
더 높은 커버리지를 원하면 단위테스트를 작성해 보자, 기능 테스트로 무척 어려운 오류상황 시뮬레이션도 단위테스트라면 쉽게 해낼수 있다.
팀 생산성 향상
단위 테스트는 다른 컴포넌트가 완료 될때 까지 기다리지 않고 품질 높은 코드를 납품할 수 있다.
회귀 테스트 수행 및 디버깅 감소
단위테스트 스위트가 통과 되었음은 코드가 정상 동작함을 증명해주고 리팩터링이나 새 기능을 추가하기 위해 코드를 수정해도 좋다는 확신을 준다.
기능 테스트가 버그 존재하는 유스케이스를 골라주는 수준이라면 단위테스트는 어떤 메서드가 어떤 이유로 실패했는지도 이야기해준다.
확신에 찬 리팩토링
단위테스트는 리팩토링 해도 좋다는 확신을 안겨주는 안정망이 되어준다.
구현 품질 현상
단위테스트는 대상 API 가 유연하고 독립적으로 테스트 가능하게 만들어질 것을 강요한다.
단위테스트를 만들고 관리할때는 단위테스트 자체도 주의 깊게 들여다 보아야함을 잊지말자.
하나의 단위테스트가 너무 길어지거나 복잡해지는 것은 대상 코드에서 나쁜냄새가 나는 경우로 이 순간 리팩터링이 필요하다.
-> 하나의 테스트 메서드에 너무 많은 기능을 테스트 하기 때문일 수도 있다.
만약 기능이 독립적으로 테스트 할 수없다면 그 기능이 충분히 유연하지 않은 상황일때까 많으니 리팩터링 해줘야한다.
기대행위 문서화
단위테스트는 API 사용법을 보여주는 예제인것 그것 자체로 훌륭한 개발 문서로 활용될 수 있다.
단위 테스트는 생산 코드와 일치하므로 다른 형태의 문서와 달리 항상 최신 상태로 유지된다는 이점도 제공된다
public class TestAcco9unt{
@Test{expected = ASccount InsufficientFundsException.class)
public void tranferWithoutEnoughFunds(){
long balance = 1000;
long amountToTransfer = 2000;
Account credit = new Account(balance);
Account debit = new Account();
credit.transfer(debit,amountToTransfer);
}
}
위 코드를 보면 1 에서 @TEST 애노테이션으로 테스트 메소드임을 알린다. 또한 expected를 통해 예외가 발생해야함을 명시한다.
2. 이체할 금액을 정한다.
3. 2000만큼 이체할 것을 요청한다.
4. 예상되로 trancsfer 메소드는 예외가 발생한다. 예외 발생 실패일시 JUnit은 테스트 실패로 처리한다.
코드 커버리지 등 각종 측정 가능
단위 테스트는 버튼을 누르는 즉시 모든 기능이 문제 없이 동작하는지 여부를 확인해준다.
나아가 테스트가 훑고 지나간 코드를 문장 단위로 보여주는 코드 커버리지 측정결과도 알려준다.
지난 빌드 실패 성공 추이를 한눈에 볼수있는 툴도 사용할 수있다. 수행 성능을 측정하여 이전 빌드 대비 안좋은 결과가 나오면 실패하는 테스트를 작성하는 것 역시 가능하다.
테스트 종류
- 단위 테스트
- 통합 테스트
- 기능 테스트
- 스트레스 테스트와 부하 테스트
- 인수 테스트
통합 테스트
개별 단위 테스트는 품질제어에 있어 필수 요소이다.
허나 여러 컴포넌트에 의해 함께 사용되는 빈도가 높은 부분일 수로 버그가 발생할 확률이 높은데 이는 단위테스트로 테스트 할 수 없는 부분이다.
그렇다면 이상적으로 애플리케이션 코드를 작성하기에 앞서 통합테스트를 정의해야한다.
- 객체간 상호작용 > 테스트 객체들을 생성하고 객체에 정의된 메서드들을 호출해야한다.
- 서비스간 상호작용 - 테스트는 서블릿이나 EJB 컨테이너가 애플리케이션을 구동하는 과정에서 실행된다.
- 서브 시스템간 상호작용 > 계층적 애플리케이션은 표현 계층을 담당하는 프론트엔드와 비즈니스 로직을 실행하는 백엔드 구성되기도 한다. 이 경우 테스트는 프론트엔드로부터 요청이 잘 전달 되어 백엔드가 적절히 응답하는지 검사할 수 잇다.
기능 테스트
기능 테스트는 공개된 API의 가장 바깥쪽에 해당하는 코드를 검사한다.
즉 애플리케이션을 유스케이스 단위로 테스트하는것
- 프레임워클를 이용하는 애플리케이션 : 프레임워크의 기능 테스트는 프레임워크 API 테스트를 집중
- GUI를 포함하는 애플리케이션 : GUI 기능테스트는 모든 기능을 사용할 수 있고 또 기대한 대로 동작하는지 검증 테스트에서 GUI를 직접 제어하는데 그 과정에서 연관된 다른 컴포넌트나 백엔드 시스템을 호출
- 서브 시스템들로 구성된 애플리케이션 : 계층적시스템의 각 계층은 전체 시스템을 역할별로 세분화한 것 표현서브 시스템, 비즈니스 로직 서브 시스템, 데이터 서브 시스템 등이 있다. 계층화는 유연성을 제공함으로써 서로 다른 프론트엔드를 통해서도 같은 백엔드에 접근할 수 있다. 각 계층은 다른 계층들에서 사용할 수 있도록 API를 제공하는데 이것이 바로 기능 테스트가 검사하는 대상이다.
스트레스 테스트
많은 사람이 동시다발적으로 사용할 때 애플리케이션은 얼마나 잘 버틸수 있을까
대부분 스트레스 테스트는 주어진 단위 시간 동안 애플리케이션이 얼마나 많은 요청을 처리할 수 있는가 검사한다.
JMeter 같은 전용 소프트웨어를 사용
스트레스 테스트를 위한 환경은 가능한 실제 운영환경과 유사하게 하는것이 좋다
JUnit 을 사용하면 각 단위테스트를 성능 테스트로 변신 시킬수 있다.
public class ExampleTimedTest{
@Test(timeout = 5000)
public void someVeryLongTest(){}
}@Test메소드에 timout 파라미터를 사용하면 5000 ms 를 넘긴다면 테스트는 실패한다는것
허나 이런 방식의 테스트는 환경이 바뀌면 제한 시간도 함께 조정해야한다는 문제가 있다.
인수 테스트
인수테스트는 우리가 정의한 테스트중 마지막 단계 , 고객이나 대리인이 애플리케이션이 곡객과 이해관계자가 정의한 모든 목적에 부합되는지 확인해보고 인수테스트 수행
단위테스트 종류 세가지
- 논리 단위 테스트 : 한 메서드에 집중한 테스트, 목 객체나 스텁을 이용해 테스트 메서드 의 경계를 제어할 수있다.
- 통합 단위 테스트 : 실제 운영환경에서 컴포넌트간 연동에 치중한 테스트
- 기능 단위 테스트 : 자극 반응을 확인하기 위해 통합 단위테스트의 경계를 확장한 테스트
이 테스트들을 잘 활용시 테스트커버리지 높아지고 코드를 수정할 때 자신감도 높아지고 새로운 결함을 만들어 낼 위험도 줄어든다.
블랙박스 테스트와 화이트 박스 테스트
블랙박스 테스트
블랙박스 테스트에서는 대상 시스템의 내부 상태와 동작에 대한 아무런 정보가 없다 테스트는 순전히 시스템 외부 인터페이스에 의존해 정확성을 검증한다.
이능 곧 프로젝트 초기부터 테스트가 가능함을 말한다.
블랙박스 테스트의 가장 단순한 혀애는 수동으로 사용자 인터페이스를 조작하는 식
툴을 사용하면 좀더 세련된 테스트가 가능한데 HttpUnit, HtmlUnit, Selenium 같은 툴이 있다.
화이트 박스 테스트
블랙박스 테스트와 반대로 테스트를 작성할때 구현에 대한 상세 지식 모두 활용
사용자 중심 접근법
곡객에게 테스트 스크립트를 주고 자기 손으로 직접 수행토록 해주기
테스트 난이도
블랙박스 테스트의 대상은 그래픽 사용자 인터페이스를 제공하는 경우가 보통 테스트 작성하고 수행하기 난해한 편이다 .
테스트 커버리지
화이트박스 테스트가 블랙박스보다 테스트커비리지가 높다.
반면 제공 가치면에서 블랙박스 테스트가 더 크다
불할 정복법 - 코드를 작성할 때 뿐만 아니라 테스트에도 똑같이 적용됨을 명심하자
즉 다양한 종류 테스트 적극 활용하여 테스트 커버리지도 높이고 맘 편히 리팩터링과 애플리케이션 개선 작업에 임하자
