|
Chapter 4
무엇을 테스트해야 하는가? (Check Point)
1. 결과가 옳은가?
2. 모든 경계 조건이 correct 한가?
3. 역관계를 확인할 수 있는가?
4. 다른 방법을 사용해도 결과를 교차 확인 할수 있는가?
5. 에러조건을 강제로 만들어 낼 수 있는가?
6. 성능 특성이 한도 내에 있는가?
2. 모든 경계 조건이 Correct 한가?
- 형식 일치
- 순서 : 적절히 순서대로 되어 이거나 그렇지 않은 값인가?
- 범위 : 적당한 최솟값과 최댓값 사이에 있는 값인가?
- 참조 : 코드가 자기가 직접 제어 하지 않는 외부 코드를 참조하는가?
- 존재 : 값이 존재하는가?(null, 0 , 집합 안에 존재함)
- 개체수 : 확실히 충분한 값이 존재하는가?
- 시간 : 모든 것이 순서대로 일어나는가? 제시간에, 때맞추어?
- 완전 엉터리거나 일관성이 없는 입력값 (!@#$%^&*()
- 잘못된 형식화된 데이터. (fred@fooba.)
- 아예 없거나 빠뜨린 값. 0,"",null,0.0
- 합리적인 예상치에서 한참 떨어진 값. 1000살이 넘는 사람 나이
- 중복된 값이 안되는 목록에서 중복된 값
- 순서가 매겨져야 하는 목록인데 순서대로 되어 있지 않은 경우.
- 잘못된 순서로 생기거나 기대한 순서와 다르게 일어나는 일. 옐르 들면 로그인하기 전에 문서를 출력하려고 시도
하는 것.
3. 역관계 확인
double x = mySquareRoot(4.0);
assertEquals(4.0,x*x,0.0001);
4. 다른 수단을 이용한 교차 확인
double root1 = mySquareRoot(4.0);
double root2 = Math.sqrt(4.0);
assertEquals(root2,root1,0.0001);
chapter5 correct 경계 조건
* 인덱스 관련 개념
- 시작 인덱스와 끝 인덱스가 같은 값이다.
- 처음 인덱스가 마지막 인덱스보다 크다
- 인덱스가 음수다.
- 인덱스가 허용된 것보다 큰 값이다.
- 원소 개수를 세는 변수값이 실제로 들어 있는 항목 개수와 맞지 않는다.
* 존재성
- null, 0, "", 그 밖의 텅빈 허무주의자의 장식들을 충분히 그리고 확실히 테스트 하라.
여러분의 메서드가 무를 확실히 이겨낼 수 있게 하라.
* 개체수
12 피트 길이의 잔디밭에 울타리를 갈게 세우려 하는데, 기둥 사이의 울타리 벽 부분은 폭이 3피트
길이라면 울타리 기둥이 몇개 필요한가? -> 울타리 기둥 에러
0-1-n 규칙 :
이는 존재성과 관련된 문제이기도 하지만, 여기에서는 개수를 정확히 필요한 만큼 갖고 있다든가,
정확히 필요한 만큼 만들었다는 것을 확인 해야 한다.
어떤 값 집합의 개체 수는 다음 세 경우만 신경쓰면 된다.
* 시간
상대시간 : 시간적 순서 (기대하는 순서에 어긋나는 메서드 호출을 시도해 봐야 할 것이다.
일련의 순서에서 처음것을, 마지막 것을, 중간 것을 생략해 보라)
절대시간: 경과한 총 계산 시간
동시상concurrency 문제. 테스트의 일부로 스레드 여러개를 돌려보도록 하라.
chapter 6. 모의 객체 사용하기
1. 간단한 스텁 (설계를 테스트 하는 동안 코드에서 임시로 만들어 사용하는 부분을 말한다.)
public long getTime(){
if(debug)
return debug_cur_time;
else
return System.currentTimeMillis();
}
우리에게 필요한 것은 똑같은 일을 해내면서 더 깔끔하고, 더 객체지향적인 방법이다.
2. 모의 객체 Mock
- 진짜 객체가 비결정적인 동작을 한다.(예상할 수 없는 결과를 만들어 낸다. 주식시장 시세처럼)
- 진짜 객체를 준비 설정하기 어렵다.
- 객체가 직접 유발시키기 어려운 동작을 한다(네트웍 에러)
- 진짜 객체가 느리다
- 진짜 객체가 사용자 인터페이스를 가지거나, 사용자 인터페이스 자체다.
- 테스트가 진짜 객체에게 그것이 어떻게 사용되었는지 물어보아야 한다(callback 함수가 호출되었는지 확인)
- 진짜 객체가 아직 존재하지 않는다.
* Servlet Test : www.mockobjects.com
chapter 7 좋은 테스트의 특징
단위 테스트를 하는 이유는 무엇보다 먼저 여러분 자신의 삶을 편하게 만들기 위해서다!
- 자동적
- 철저함
- 반복가능
- 독립적
- 전문적
-자동적
cruisecontrol.sourcdforge.net
www.cs.unibo.it/projects/anthill
www.mozilla.org/tinderbox.html
-철저함
nounit.sourceforge.net
quilt.sourceforge.net
패치하지 말고, 재작성하라. 종종 버그 뭉치를 안고 있는 코드 부분을 버리고
무에서 출발해 그것을 재작성하ㅡㄴ 편이 비용도 훨씬 적게 들고 덜 고통스러운 방식일 수 있다.
-반복가능
모든 개발자는 그 안에서 놀 수 있는 자기만의 모래 상자를 필요로 한다.
-전문적
단위테스트코드가 제품 코드와 마찬가지로 전문적 표준을 유지하면서 작성되어야 한다.
좋은 서례글 위한 모든 일반적인 규칙, 캡슐화 유지, Dry원칙 지키기
- 테스트를 테스트 하기
1. 버그를 식별한다.
2. 실패하는 텟트를 작성한다. (버그가 있다는 것을 증명)
3. 코드를 고쳐서 이제 테스트를 통과하게 만든다.
4. 코든 테스트가 지금도 통과 한다는 것을 확인한다. ( 즉, 이 수정작업 때문에 망가뜨린것들이 없다는 뜻이다)
chapter 8 프로젝트에서 테스트하기
1. 테스트 코드를 어디에 둘것인가
- 직렬, 병렬, 혼합
2. 테스트 예절
3. 테스트 빈도
- 새 메서드를 작성할때마다
- 버그를 고칠때마다
- 성공적으로 컴파일할 때마다
- 버그 관리 시스템에 체크인할 때마다
- 끊임없이
4. 테스트와 레거시 코드
- 유지보수중인 코드인경우, 가장 망가진부분의 테스트 코드를 작성하라
5. 테스트와 검토
- 테스트코드의 검토
|
