Blog
yagur.impon.net/#blog
Tumblr
yagur.tumblr.com
Live Photo
photo.live.com/…
Dopplr
dopplr.com/traveller/yagur
YouTube
youtube.com/TheYagur
Last.fm
last.fm/user/yagurchoi
Diigo
diigo.com/yagur
Ember
emberapp.com/yagur
Twitter
twitter.com/YagurChoi
Readernaut
yagur.userstorybook.net/
'테스트와장인'에 해당되는 글 10건
- 2008/09/30 테스트와 장인 - 10
- 2008/07/12 테스트와 장인 - 9
- 2008/03/19 테스트와 장인 - 8
- 2008/03/12 테스트와 장인 - 7
- 2008/02/25 테스트와 장인 - 6(2)
- 2008/02/22 테스트와 장인 - 5
- 2008/02/21 테스트와 장인 - 4(2)
- 2008/02/19 테스트와 장인 - 3(6)
- 2008/02/15 테스트와 장인 - 2
- 2008/02/14 테스트와 장인 - 1(2)
작성자 : yagur rev : 2
GPS로 위치를 정확히 알수만 있다면, 하지만 현실은 추정으로 이루어진 지도와 육분의뿐이다.
테스트 항해(Test Nevigation)
먼 곳으로 항해하는 배가 풍파를 만나지 않고 조용히만 갈 수 는 없다. 풍파는 언제나 전진하는 자의 벗이다.
- 니체
항해의 주 목표는 목표 지점에 정확히 안전하게 가는 것이지만, 좋은 위치 측량없이는 힘들다. '명세에 맞는 결함이 적은 코드 생산'을 목표 지점으로하는 항해를 하기 위해선 위치 측정이 중요하다. 육분의는 현재 위치를 측정할수 있는 좋은 도구이다.
프로그램을 작성하면서 코드의 결함도를 측정하는 행위는 단위테스트이다. 이는 프로그램이 시간의 흐름에 따라 점진적으로 크기가 커질때 그 신뢰도(완성도)가 어느 위치에 있는지 알려주기때문에, 항해의 육분의와 유사하다. 항해에 GPS가 마련되있으니 육분의 사용이 필요 없는 팀이나 개인은 손으로 꼽을수 있을것이라 생각한다. 대부분은 덜 명확한 지도(명세, 달성 목표, 설계)를 보고 목표를 향해 항해할것이다.
GPS를 사용할수 없어서, 육분의로 항해하는 배는 삼각측량법을 사용한다. 이를 위해 항해사는 세개의 육분의를 사용한다. 그 이유는 육분의의 오차때문이다. 측정오차는 0.5′(분; 1°= 60")정도라고 한다. 짧은 거리(작은 소프트웨어)를 항해할때는 하나의 육분의로도 목표에 근접할수 있겠지만, 먼 거리를 항해할때 오차는 목표로부터 꾀 먼거리에 도달하게 만든다. 측정 반복 과정이 짧다고 가정했을때, 최악의 경우는 측정 반복 횟수와 시간의 증가에 따라 오차 최대치가 누적될것이다.
하나의 육분의로 측정할때, 그리고 두개로 측정할때는 다르다. 두개로 측정할때는 두 결과물을 놓고 비교하기 때문에, 좀더 정확한 위치에 가까워지거나, 어느 육분의에 오류가 있는지 알아낼 확률이 높아진다. 세개가 있을때는 말할것 없이 두개보다 측정값이 더 정확해질 확률이 높다.
테스팅의 세계로 돌아와 보자. 한개의 검증이 존재하는 단위테스트를 패스한 테스트 대상이 오동작활 확률을 50%로 가정한다면, 두개가 존재할때는 25%, 세개가 존재할때는 12.5%가 될것이다. 물론 코드 테스팅은 논리의 구현를 검증하는 행위이기 때문에 물리적인 측량과는 다르다.
아래는 절대값을 구하는 작위적인 테스트이다.
int abs(int i)
{
return -i;
}
}
TEST(abs)
{
FAIL_IF(abs(-1) != 1);
}
}
단위 테스트안에 하나의 검증이 존재할때의 상황이다. abs(1)이 들어간다면 어떠할까. 테스트를 통과해 신뢰성이 높아졌다고 생각했던 abs가 당신을 배신했다.
int abs(int i)
{
return -i;
}
}
TEST(abs)
{
FAIL_IF(abs(-1) != 1);
FAIL_IF(abs(1) != 1);
}
}
이제 빨간막대를 볼수 있다.
int abs(int i)
{
if(i < 0)
return -i;
return i;
}
}
이것이 녹색막대를 보여주는 절대값 함수이다. CC(CyclomaticComplexity)는 2이다. CC가 증가함에 따라 오류를 낮추기 위해 검증 횟수 역시 증가된것을 볼수있다. 위의 예는 반대 순서로 흘렀지만, 다른 길이가 길어진 프로시저들의 CC가 증가하면 그것을 검증하는 비용을 역시 증가한다.
Carnegie Mellon의 CC표.(Edmond VanDoren, Kaman Sciences, Colorado Springs)
| Cyclomatic Complexity | Risk Evaluation |
| 1 - 10 | a simple program, without much risk |
| 11 - 20 | more complex, moderate risk |
| 21- 50 | complex, high risk program |
| > 50 | untestable program (very high risk) |
오차 확률이 누적되 항로가 많이 달라졌더라도, 적당한수의 육분의가 있다면 항로를 원래 항로로 맞출 확률은 더 높아진다. 그렇다고 모든 경우에 삼각측량법을 사용하란것은 아니다. 하지만 무의식중에 자주쓰고있는 방법임은 분명하다.
하지만 우연적인 방법에서 한단계 올라가자면 의도적으로 삼각측량법을 쓰는것이다. 테스트를 우연에 맞기겠는가? 아니면 의도적으로 오류검출 확률을 높히겠는가? 테스트는 부시기 위한 테스트인가? 아니면 통과하기 위한 테스트인가? 의도적으로 방법을 쓰지 않았다면 이 질문에 대해 생각해보는것이 시간낭비가 되진 않을것이다.
개발자 테스트는 "깨끗한 테스트"가 되기 쉽다. - Boris Beizer 1994
하지만 우연적인 방법에서 한단계 올라가자면 의도적으로 삼각측량법을 쓰는것이다. 테스트를 우연에 맞기겠는가? 아니면 의도적으로 오류검출 확률을 높히겠는가? 테스트는 부시기 위한 테스트인가? 아니면 통과하기 위한 테스트인가? 의도적으로 방법을 쓰지 않았다면 이 질문에 대해 생각해보는것이 시간낭비가 되진 않을것이다.
나는 어떤 계산을 어떻게 해야 올바르게 추상화할 것인지에 대해 정말 감잡기 어려울 때만 삼각측량을 사용한다.
- Kent Beck(테스트 주도 개발중)
나의 경우엔 처음 테스팅을 시작할때, 명백해 보이는 것들도 빨간막대를 보이는 경우가 많았다. 삼각측량법으로 접근하고, 추상화되거나 의미 없는 테스트가 되었을땐 삼각측량법으로 인해 증가한 검증들을 과감히 삭제해도 좋다. 하지만 저들이 검증에 도움이 되보이는 경우가 많다 생각하여, 보통의 경우 삭제하지 않는다. 그 명백함을 지니는것으로 보이는 함수의 구현이 변경될때를 대비해서이다. 모든 테스트가 수식으로만 이루어진 함수를 대상으로 하지 않는다는 것을 생각해보면 된다.
목표에 좀더 정확히 다가가기 위해서는, 현재 위치가 중요하다. 풍랑과 같은 예측 불가한 위험은 항로를 이탈하게 만든다. 작은 검증 추가(삼각측량법)가 예측 불가한 위험으로부터 항해를 지켜줄것이다.
'개발 > 수필' 카테고리의 다른 글
| 테스트와 장인 - 10 (0) | 2008/09/30 |
|---|---|
| 테스트와 장인 - 9 (0) | 2008/07/12 |
| 객체 지향 소프트웨어 일주 - 5 (0) | 2008/05/18 |
| 객체 지향 소프트웨어 일주 - 4 (0) | 2008/05/08 |
| 객체 지향 소프트웨어 일주 - 3 (0) | 2008/03/28 |
| 테스트와 장인 - 8 (0) | 2008/03/19 |
작성자: yagur Rev : 1
테스트 측정(Test Measurements)
나는 어림짐작은 안 한다네. 그건 논리적인 사고력을 파괴하는 끔찍한 습관이지
- 셜록 홈즈(아서 코난 도일)
테스트는 제품의 품질을 개선하거나 일부 항목을 검증하는 행위이다. Steve McConnell은 소프트웨어의 경우 외적으론 정확성correctness, 유용성usability, 효율성efficiency, 신뢰성reliability, 무결성integrity, 적응성adaptability, 정밀성accuracy, 견고성robustness에 영향을 미치며 내적으로는 유지 보수성maintainability, 유연성flexibility, 이식성portability, 재사용성reusability, 가독성readability등에 영향을 미친다고 한다. 아쉽게도 이 모든 사항이 어떤 측정 단위로 눈에 보여지는것은 아니다.
실세계의 제품은 테스트시 누구나 납득할만한 측정 단위로 테스트의 결과가 표현되며, 제품의 성능을 홍보할때도 많이 활용된다. 예를 들면 Bugatti Veyron은 세계에서 가장 빠른차라고 그들의 차를 홍보하며 제로백을 2.8초 최대속도 407km라고 소개한다.
위의 동영상은 부가티 베이론을 독일에 위치한 60마일 정도 되는 테스팅 트랙에서 테스트한 결과이다. 속도 변화를 보여주는데 그들은 km/h 단위로 측정하고 있다. 그들은 차량을 테스트 하며 목표 속도나 시간을 단위로 해 시스템 테스트를 진행하고 개선해 나갈것이다.
컴퓨터 부품인 Nvidia사의 GForce 9600 GT도 아래와 같은 성능을 내걸고 홍보한다.
Memory Bandwidth (GB/sec) 57.6
Texture Fill Rate (billion/sec) 20.8
Texture Fill Rate (billion/sec) 20.8
하드웨어의 경우 동력 대비 성능과 같은 효율성 측정이 있다. 예를 들자면 인텔 CPU는 풀 로드와 대기 상태의 전력소비량을 내세워 광고하고있다. 소프트웨어라면 어떠할까? 메모리 사용량과 실행 시간 같은 요소을 명세에 맞춰 효율성을 측정할수 있다. 하지만 이들은 물리적 효율성을 측정한것이다. 구조적 효율성의 변화를 테스트를 통해 개선해 나간다면 다른 단위가 필요하다. 이에 관해 Robert C. Martin은 몇가지 측량법metric을 소개한다.
1. 클래스의 숫자와 인터페이스의 숫자
추상 객체, 구체적 객체, 인터페이스의 숫자는 확장성의 지표가 될수 있다.
2. 결합도의 수입성數入性 - Ca 다른 클래스(측정 대상외의것)가 측정 대상의 클래스에 얼마나 의존하는가를 수치로 나타낸것은, 측정 대상의 책임성의 지표가 될수 있다.
3. 결합도의 수출성輸出性 - Ce 측정 대상의 클래스가 다른 클래스(측정 대상 외의 것)에 얼마나 의존하는가를 수치로 나타낸것은, 측정 대상의 독립성의 지표가 될수 있다.
4. 추상성Abstractness - A측정 혹은 분석 대상의 추상객체 혹은 인터페이스의 비율을 나타낸다. 범위는 0과 1사이이다.
5. 불안전성Instability - I 결합도의 수출성과 총 결합도의 비율을 나타낸다. I = Ce/(Ce+Ca). 이 측정값은 변경으로 부터의 복원성의 지표가 될수 있다.
테스트를 거듭하여 변경된 구조의 상태를 위의 측량법으로 측정하는 것이 추측에서 벗어난 방법, 즉 객관적이 되는데 도움이 될것이다. 물론 저들로 효율성을 전체를 판단할순 없지만, 측정기준이 없는것 보다 낫다.
예를들어 0.3 A를 가진 테스트 대상 컴포넌트나 패키지는 추상적인 객체나 인터페이스로 접근성을 높혀준다. 또한 대상(0.3 A를 가진 테스트 대상)과 결합하는 응용 프로그램의 결합도 수출성(Ce)이 높다 하더라도, 결합 대상들의 추상성(A)이 적당하다면 불안전성(I)을 완화 해줄 확률이 높아진다.
때때로 우리는 테스트를 통해 성능이나 안전성 외의 것을 생각해봐야한다. 어떤 구조개선을 이루고 있는것인지 직감에만 의존하는것은 아닐까.
마지막으로 맥코넬이 제시했던 요소들간의 영향력 차트이다.
'개발 > 수필' 카테고리의 다른 글
| 테스트와 장인 - 10 (0) | 2008/09/30 |
|---|---|
| 테스트와 장인 - 9 (0) | 2008/07/12 |
| 객체 지향 소프트웨어 일주 - 5 (0) | 2008/05/18 |
| 객체 지향 소프트웨어 일주 - 4 (0) | 2008/05/08 |
| 객체 지향 소프트웨어 일주 - 3 (0) | 2008/03/28 |
| 테스트와 장인 - 8 (0) | 2008/03/19 |
작성자: yagur Rev : 1
모의 객체(Mock Object)
프레임 워크와 같은것은 테스트 도구이지만 도구로 할수 있는 테스트 커버리지는 제한적이다. 그 제한 커버리지를 넓히것엔 여러 패턴과 방법이 동원된다. 그리고 이들은 결과물의 완성도를 높히는데 필요하다. 많은 테스트 패턴과 방법들은 모의 객체Mock Object를 동반 하는 경우가 많다. 그 중 BMW란 자동차 생산 업체는 모의 객체를 훌륭히 활용하고 있다.
자동차를 고르는 기준은 많이 있다. 주행능력, 승차감, 디자인과 같은 것들이다. 이들 외에도 우리는 안전성을 본다. 사고시 차의 상태변화와 운전사를 포함한 탑승자의 안전상태를 중요하게 여기게 된것이다. 그럴수 밖에 없는 것이 자동차 사고로 죽는 사람의 숫자는 상상을 초월하기 때문이다. 이런 문제점을 받아들인 장인들의 제품(차)들은 견고함과 사고 대처 능력이 매우 뛰어나다고 알려져있다. 단지 소문만으로 저런 명성을 얻기는 힘들다. 저들은 모의 테스트라는 것을 통해 그 능력을 입증하고 있다.
저들은 따로 차량 안전 센터에서 다중 충돌 테스트를 한다. 완성된 차량에 여러 방향에서 차량 충돌을 가하는데 모의 부품이 어디에 있는지 반문하는 분들도 계실것이다. 하지만 다시 본다면 모의 객체는 존재한다.
테스트의 목적은 탑승자의 안전이다. 하지만 어느 회사도 실제 사람을 차량 안전 테스트용으로 쓸수 없을 것이다. 여기서 그들(자동차 생산 벤더)이 고안해낸 것은 모의 객체인 차량 충돌 인형(crash dummy)이다.
좌측은 충돌 테스트, 우측은 부분 충격 테스트
크래쉬 더미는 사람과 비슷한 모양과 관절 구조를 지니고 있다. 그리하여 충돌시 어느 부위에 어떤량의 충격을 어떤 형태로 받는지 시험해보기 좋게 설계되어있다. 이런 형태를 가진 개체의 객체를 모의 객체라 하며, 소프트웨어와 하드웨어를 구분하지 않고 널리 사용되고 있다.
특정 부분의 내구성이나 동작을 보기 위해 시스템 전체를 매번 테스트 하는것은 비용이 많이 소모된다. 그리 하여 특정 부분을 분리해내고 모의 환경을 조성해 테스트를 한다. 이럴 경우 비용은 매우 감소되며, 좀더 많은 횟수의 정밀한 테스트를 할수 있게 된다. 또 사용된 모의 환경과 객체는 개선된 제품의 테스트를 위해 재사용 될수 있으므로 일석이조이다.
Crash Dummy Evolution
일석삼조가 될수도 있다. 모의 객체에 하나의 제품의 의미를 둘수있는데, 이는 모의 객체 역시 제품 테스트 과정에서 진화하기 때문이다. 모의 객체가 재사용 가능한 하나의 제품이 되는것이다. 예를 들면 충돌 테스트 더미와 같을것이다. 처음엔 관절도 거의 없고, 센서도 몇개 없었을 것이다. 허나 충돌 테스트 방향이 많아지고, 사고로 인한 사고 부위가 다양히 들어남에 따라 관절도 늘고, 충돌시 충격량을 체크하기 위한 센서도 늘어났을 것이다.
좌측의 사진은 크래쉬 더미(Mock Object)의 진화형태이다. 갈비 뼈까지 재현해 내고있다. 저 정도 모의 객체라면 상품적 가치도 있을것으로 보인다. 실제 국제 크래쉬 더미로 쓰인다고 한다.
그리고 우린 모의 객체의 활용의 실례를 "6.테스트 의존성의 함정"에 있는 Self Shunt에서 찾아 볼수 있었다.
모의 환경(Mock Environment)
소프트웨어에서 모의 객체는 여러 방면으로 쓰일수 있다. 그중 하나는 모의 객체가 모의 환경으로서의 역활을 하는 경우이다. 모의 환경으로서의 한 예는 디스크 입출력을 예로 들수 있다. 디스크 입출력 환경을 모의 객체로 지정하고, 테스트 시에는 메모리에 입출력을 진행하여 테스트 속도를 높힐수 있다. 그리고 입출력 내용도 쉽게 확인할수 있다.
물론 물리 디스크와 환경이 같지 않으므로 특정 퍼포먼스에 관련된 테스트는 실제 디스크에 입출력을 행하여야 정확한 결과를 얻을수 있다. 하지만 기록 내용 확인 차원과 같은 테스트는 메모리에 기록함으로서 테스트 수행 시간을 단축시킬수 있다. 또 디스크 공간이 부족한 경우를 시뮬레이션 시키거나, 강제로 입출력의 실패를 모의 시험할때 쓸수 있다.
이런 모의 환경 객체들은 하나의 단위 테스트 외에도 여러 다른 테스트에 재사용 될 수 있으며, 경우에 따라 상품의 가치를 지닐수도 있다. 그 예로는 Compuware의 Boundschecker와 같은 메모리 누수 진단 도구를 들수 있다.
Compuware의 Devpartner 바운즈체커는 메모리의 생성, 해제의 환경을 모의로 조성 함(후킹?)으로서 어디서 메모리 누수가 일어나는지 리포트 해주는 툴이다. 실행 환경중 메모리 관련 부분을 후킹하고 오버라이드 함으로서 사용자의 '메모리 누수에 관련된 스트레스 테스트 환경'을 훌륭히 조성해준다. 물론 사용자가 별도로 메모리 관련 오퍼레이터나 함수를 오버라이드해 테스트 해볼수도 있다. 하지만 좀더 전문화된 테스트환경을 조성하기 위해선 바운즈 체커를 고려해볼수도 있다. 하지만 $1800 란 가격은 IDE의 애드인치고는 비싼편이다. 단 이같은 툴을 만들기 위해 경력의 프로그래머를 한달 쓴다 해도 더 좋은 기능의 툴이 나오기를 기대하긴 힘들다.
모의 객체(Mock Object)
프레임 워크와 같은것은 테스트 도구이지만 도구로 할수 있는 테스트 커버리지는 제한적이다. 그 제한 커버리지를 넓히것엔 여러 패턴과 방법이 동원된다. 그리고 이들은 결과물의 완성도를 높히는데 필요하다. 많은 테스트 패턴과 방법들은 모의 객체Mock Object를 동반 하는 경우가 많다. 그 중 BMW란 자동차 생산 업체는 모의 객체를 훌륭히 활용하고 있다.
자동차를 고르는 기준은 많이 있다. 주행능력, 승차감, 디자인과 같은 것들이다. 이들 외에도 우리는 안전성을 본다. 사고시 차의 상태변화와 운전사를 포함한 탑승자의 안전상태를 중요하게 여기게 된것이다. 그럴수 밖에 없는 것이 자동차 사고로 죽는 사람의 숫자는 상상을 초월하기 때문이다. 이런 문제점을 받아들인 장인들의 제품(차)들은 견고함과 사고 대처 능력이 매우 뛰어나다고 알려져있다. 단지 소문만으로 저런 명성을 얻기는 힘들다. 저들은 모의 테스트라는 것을 통해 그 능력을 입증하고 있다.
저들은 따로 차량 안전 센터에서 다중 충돌 테스트를 한다. 완성된 차량에 여러 방향에서 차량 충돌을 가하는데 모의 부품이 어디에 있는지 반문하는 분들도 계실것이다. 하지만 다시 본다면 모의 객체는 존재한다.
테스트의 목적은 탑승자의 안전이다. 하지만 어느 회사도 실제 사람을 차량 안전 테스트용으로 쓸수 없을 것이다. 여기서 그들(자동차 생산 벤더)이 고안해낸 것은 모의 객체인 차량 충돌 인형(crash dummy)이다.
크래쉬 더미는 사람과 비슷한 모양과 관절 구조를 지니고 있다. 그리하여 충돌시 어느 부위에 어떤량의 충격을 어떤 형태로 받는지 시험해보기 좋게 설계되어있다. 이런 형태를 가진 개체의 객체를 모의 객체라 하며, 소프트웨어와 하드웨어를 구분하지 않고 널리 사용되고 있다.
특정 부분의 내구성이나 동작을 보기 위해 시스템 전체를 매번 테스트 하는것은 비용이 많이 소모된다. 그리 하여 특정 부분을 분리해내고 모의 환경을 조성해 테스트를 한다. 이럴 경우 비용은 매우 감소되며, 좀더 많은 횟수의 정밀한 테스트를 할수 있게 된다. 또 사용된 모의 환경과 객체는 개선된 제품의 테스트를 위해 재사용 될수 있으므로 일석이조이다.
좌측의 사진은 크래쉬 더미(Mock Object)의 진화형태이다. 갈비 뼈까지 재현해 내고있다. 저 정도 모의 객체라면 상품적 가치도 있을것으로 보인다. 실제 국제 크래쉬 더미로 쓰인다고 한다.
그리고 우린 모의 객체의 활용의 실례를 "6.테스트 의존성의 함정"에 있는 Self Shunt에서 찾아 볼수 있었다.
모의 환경(Mock Environment)
소프트웨어에서 모의 객체는 여러 방면으로 쓰일수 있다. 그중 하나는 모의 객체가 모의 환경으로서의 역활을 하는 경우이다. 모의 환경으로서의 한 예는 디스크 입출력을 예로 들수 있다. 디스크 입출력 환경을 모의 객체로 지정하고, 테스트 시에는 메모리에 입출력을 진행하여 테스트 속도를 높힐수 있다. 그리고 입출력 내용도 쉽게 확인할수 있다.
물론 물리 디스크와 환경이 같지 않으므로 특정 퍼포먼스에 관련된 테스트는 실제 디스크에 입출력을 행하여야 정확한 결과를 얻을수 있다. 하지만 기록 내용 확인 차원과 같은 테스트는 메모리에 기록함으로서 테스트 수행 시간을 단축시킬수 있다. 또 디스크 공간이 부족한 경우를 시뮬레이션 시키거나, 강제로 입출력의 실패를 모의 시험할때 쓸수 있다.
이런 모의 환경 객체들은 하나의 단위 테스트 외에도 여러 다른 테스트에 재사용 될 수 있으며, 경우에 따라 상품의 가치를 지닐수도 있다. 그 예로는 Compuware의 Boundschecker와 같은 메모리 누수 진단 도구를 들수 있다.
'개발 > 수필' 카테고리의 다른 글
| 객체 지향 소프트웨어 일주 - 4 (0) | 2008/05/08 |
|---|---|
| 객체 지향 소프트웨어 일주 - 3 (0) | 2008/03/28 |
| 테스트와 장인 - 8 (0) | 2008/03/19 |
| 객체 지향 소프트웨어 일주 - 2 (2) | 2008/03/15 |
| 테스트와 장인 - 7 (0) | 2008/03/12 |
| 객체 지향 소프트웨어 일주 - 1 (0) | 2008/03/11 |
작성자: yagur Rev : 3
프레임워크 러프 스케치
동기, 주기, 새로운 프레임워크 디자인, 복잡도, 엔트로피, 그리고 함정에 관한것들이 이전 내용이었다. 이는 새로운 프레임워크 구성을 구상하고 구체화하기 전에 고려해야할 사항들이다. 많은 것을 고려할수 밖에 없는 이유는 프레임워크가 작성할 테스트에 사용될때 그 결합도가 높기때문이다(테스트가 프레임워크에 기반을 두고 있는점을 생각해보면 된다). 결합도가 높으면 변경의 영향력이 크다.
프레임워크는 OCP(Open Close Principle)를 잊지 말아야한다. 일단 작성된 프레임워크는 다른 소프트웨어의 테스트에 사용되기 때문에 변경이 있을경우, 자칫 다른 테스트를 전부 변경해야하는 상황이 생기기 때문이다. 하지만 OCP때문에 프레임워크의 진화를 망설여서는 안된다, 새로운 개념을 도입하고 그에 합당한 디자인 변경이 생긴다면 해야한다. OCP는 한가지의 원칙일뿐, 도약을 방해해선 안된다. 원칙과 도약중 어느것의 가치가 큰지는 사용자가 판단할 몫이다. 하지만 원칙을 지키려 노력한 디자인는 진화의 비용을 줄여줄것이다.
우회방법도 존재 한다. 그중 하나는 JUnit과 같이 메이저 버전을 두어 분리 시킬수 있다. 그들은 테스트 프로젝트를 만들때 JUnit3, 4를 선택할수 있게 만들어 놓았다. 하지만 이것은 근본적인 해결책은아니다.
우리가 사용할 테스트 프레임워크가 필요로 하는 명세가 항상 같을것이면 행복할것이다. 그러나 소프트웨어는 계속 변화하는 성질을 가지고 있으며 테스트를 위한 명세는 변하게 될것이다. 명세와 계획은 바뀔것이고 프레임워크의 진화를 막긴 힘들다.
스케치는 구체적인것을 실행하기전에 도움이 된다. 그림을 그릴때도 마찬가지이고, 프로그램을 작성할때도 마찬가지이다.
Deployment Diagram
지금 제작해 사용중인 테스트 프레임워크의 배치 다이어그램Deployment Diagram이며 단순 참고용으로 보면 된다. 사용자는 정의된 한가지의 프레임워크에만 의존하며 되며 그들은 사용 목적에 따라 각자의 컴포넌트를 동적 로드하고 사용하게 된다.
테스트 프레임워크, 컴포넌트 설계(Component Design of Test Framework)
뷰를 실시간 뷰와 정적 뷰로 나누었다. 이유는 상황에 따라 필요 컴포넌트가 다르기 때문이다. 테스트 주도 개발(TDD)을 하며 실시간 뷰를 요구할수도 있고, 자동화된 연속 통합continuous integration을 위해 단순 리포트만이 필요할수도 있기때문이다. 혹은 실시간 뷰로 보며, 테스트가 끝나면 리포트를 웹싸이트에 올리기를 바랄수도 있다. 필요에 의해 컴포넌트를 사용하면 되며 이는 사용자가 의존하는 TestFramework 컴포넌트에서 처리하면 된다.
테스트 모델 설계(Model of Test Framework)
실제로 사용하고 있는 모델이며, 단순 사례로 참고하길 바란다. 프레임워크 사용자는 자세히 몰라도 되거나 Factory나 몇몇 매크로에 의존하게 된다. 다중 상속이 싫거나, 언어에서 지원이 되지 않는다면 위임Delegation을 활용하면 된다. TestNode에서 수많은 노드 타입들로 확장을 하고 있는것이 싫다면, 속성을 활용하도록 디자인을 변경할수 있다.
위의 디자인은 테스트 노드가 하위 Node 혹은 Leaf, 그리고 Depedency를 연결을 할때 상세한 정책Policy을 두기를 원해서이다. 정책 결정을 다른 객체에 위임하기위한 Proxy로서 확장Extend을 하였다.(여기서 정책의 예로 한가지 들어보자면 Class Test의 하위 테스트로 System Test가 될수 없는것과 같은것이다.)
TestSuite와 TestObject는 상속과 집합 환계로 이루어져 있는데 이것은 Composite Pattern이고 TestObject는 Observable이며 View 컴포넌트 객체들은 Observer가 될것이다.
부트 스트랩 (Boot Strap)
부트 스트래핑은 스스로 자기의 신발끈을 당겨서 자신을 공중에 띄워야 하는 것과 같은 모순적 상황을 일컫는다. 바퀴를 재발명해 기능을 추가하여 사용하려면 대상의 테스트가 필요하다. 테스트를 하기위한 프레임워크를 테스트하라니? 좀 모순된 상황처럼 받아들일수 있다. 일종의 자기 참조Self Referencial 프로그래밍이 될수 있는데, 이럴때는 구조적인것이 아니며 가장 단순한 형태인 함수만 활용하는것도 하나의 방법이다. 각 객체 단위별 검증을 위한 함수를 작성하여 실행하면 일정 부분 검증이 된다. 이런 형태로 커버리지를 전체로 늘려 나가면 된다. 복잡한 구조를 띌 필요가 없는 장점이 있이 있으나, 절차적Procedural이기 때문에 실행 순서를 수동적으로 고민해야한다.
다른 방법으로는 가장 간단한 테스트 프레임워크로부터 시작해 다음 세대 프레임워크를 검증하면된다. 이것은 마치 컴파일러 작성을 위해 이전 세대의 컴파일러를 활용하는것과 같다. 그리고 다음 세대 컴파일러는 이전 세대의 컴파일러로 작성된다. 그리고 이들은 계속 이전 세대의 것을 활용해 다음 세대의 것으로 진화할것이다.
Visual C++ Compiler Bootstrap(추측)
테스트 프레임워크도 같은 원리로 진화할수 있다.
프레임워크 러프 스케치
동기, 주기, 새로운 프레임워크 디자인, 복잡도, 엔트로피, 그리고 함정에 관한것들이 이전 내용이었다. 이는 새로운 프레임워크 구성을 구상하고 구체화하기 전에 고려해야할 사항들이다. 많은 것을 고려할수 밖에 없는 이유는 프레임워크가 작성할 테스트에 사용될때 그 결합도가 높기때문이다(테스트가 프레임워크에 기반을 두고 있는점을 생각해보면 된다). 결합도가 높으면 변경의 영향력이 크다.
프레임워크는 OCP(Open Close Principle)를 잊지 말아야한다. 일단 작성된 프레임워크는 다른 소프트웨어의 테스트에 사용되기 때문에 변경이 있을경우, 자칫 다른 테스트를 전부 변경해야하는 상황이 생기기 때문이다. 하지만 OCP때문에 프레임워크의 진화를 망설여서는 안된다, 새로운 개념을 도입하고 그에 합당한 디자인 변경이 생긴다면 해야한다. OCP는 한가지의 원칙일뿐, 도약을 방해해선 안된다. 원칙과 도약중 어느것의 가치가 큰지는 사용자가 판단할 몫이다. 하지만 원칙을 지키려 노력한 디자인는 진화의 비용을 줄여줄것이다.
우회방법도 존재 한다. 그중 하나는 JUnit과 같이 메이저 버전을 두어 분리 시킬수 있다. 그들은 테스트 프로젝트를 만들때 JUnit3, 4를 선택할수 있게 만들어 놓았다. 하지만 이것은 근본적인 해결책은아니다.
적을 만나면 계획은 바뀐다 - 헬무트 폰 몰트케
우리가 사용할 테스트 프레임워크가 필요로 하는 명세가 항상 같을것이면 행복할것이다. 그러나 소프트웨어는 계속 변화하는 성질을 가지고 있으며 테스트를 위한 명세는 변하게 될것이다. 명세와 계획은 바뀔것이고 프레임워크의 진화를 막긴 힘들다.
스케치는 구체적인것을 실행하기전에 도움이 된다. 그림을 그릴때도 마찬가지이고, 프로그램을 작성할때도 마찬가지이다.
지금 제작해 사용중인 테스트 프레임워크의 배치 다이어그램Deployment Diagram이며 단순 참고용으로 보면 된다. 사용자는 정의된 한가지의 프레임워크에만 의존하며 되며 그들은 사용 목적에 따라 각자의 컴포넌트를 동적 로드하고 사용하게 된다.
테스트 프레임워크, 컴포넌트 설계(Component Design of Test Framework)
뷰를 실시간 뷰와 정적 뷰로 나누었다. 이유는 상황에 따라 필요 컴포넌트가 다르기 때문이다. 테스트 주도 개발(TDD)을 하며 실시간 뷰를 요구할수도 있고, 자동화된 연속 통합continuous integration을 위해 단순 리포트만이 필요할수도 있기때문이다. 혹은 실시간 뷰로 보며, 테스트가 끝나면 리포트를 웹싸이트에 올리기를 바랄수도 있다. 필요에 의해 컴포넌트를 사용하면 되며 이는 사용자가 의존하는 TestFramework 컴포넌트에서 처리하면 된다.
테스트 모델 설계(Model of Test Framework)
실제로 사용하고 있는 모델이며, 단순 사례로 참고하길 바란다. 프레임워크 사용자는 자세히 몰라도 되거나 Factory나 몇몇 매크로에 의존하게 된다. 다중 상속이 싫거나, 언어에서 지원이 되지 않는다면 위임Delegation을 활용하면 된다. TestNode에서 수많은 노드 타입들로 확장을 하고 있는것이 싫다면, 속성을 활용하도록 디자인을 변경할수 있다.
위의 디자인은 테스트 노드가 하위 Node 혹은 Leaf, 그리고 Depedency를 연결을 할때 상세한 정책Policy을 두기를 원해서이다. 정책 결정을 다른 객체에 위임하기위한 Proxy로서 확장Extend을 하였다.(여기서 정책의 예로 한가지 들어보자면 Class Test의 하위 테스트로 System Test가 될수 없는것과 같은것이다.)
TestSuite와 TestObject는 상속과 집합 환계로 이루어져 있는데 이것은 Composite Pattern이고 TestObject는 Observable이며 View 컴포넌트 객체들은 Observer가 될것이다.
부트 스트랩 (Boot Strap)
부트 스트래핑은 스스로 자기의 신발끈을 당겨서 자신을 공중에 띄워야 하는 것과 같은 모순적 상황을 일컫는다. 바퀴를 재발명해 기능을 추가하여 사용하려면 대상의 테스트가 필요하다. 테스트를 하기위한 프레임워크를 테스트하라니? 좀 모순된 상황처럼 받아들일수 있다. 일종의 자기 참조Self Referencial 프로그래밍이 될수 있는데, 이럴때는 구조적인것이 아니며 가장 단순한 형태인 함수만 활용하는것도 하나의 방법이다. 각 객체 단위별 검증을 위한 함수를 작성하여 실행하면 일정 부분 검증이 된다. 이런 형태로 커버리지를 전체로 늘려 나가면 된다. 복잡한 구조를 띌 필요가 없는 장점이 있이 있으나, 절차적Procedural이기 때문에 실행 순서를 수동적으로 고민해야한다.
다른 방법으로는 가장 간단한 테스트 프레임워크로부터 시작해 다음 세대 프레임워크를 검증하면된다. 이것은 마치 컴파일러 작성을 위해 이전 세대의 컴파일러를 활용하는것과 같다. 그리고 다음 세대 컴파일러는 이전 세대의 컴파일러로 작성된다. 그리고 이들은 계속 이전 세대의 것을 활용해 다음 세대의 것으로 진화할것이다.
테스트 프레임워크도 같은 원리로 진화할수 있다.
'개발 > 수필' 카테고리의 다른 글
| 테스트와 장인 - 8 (0) | 2008/03/19 |
|---|---|
| 객체 지향 소프트웨어 일주 - 2 (2) | 2008/03/15 |
| 테스트와 장인 - 7 (0) | 2008/03/12 |
| 객체 지향 소프트웨어 일주 - 1 (0) | 2008/03/11 |
| 테스트와 장인 - 6 (2) | 2008/02/25 |
| 테스트와 장인 - 5 (0) | 2008/02/22 |
작성자: yagur Rev : 5
테스트 의존성의 함정(Trap of Test Dependencies)
1. 규칙
테스트가 테스트 대상의 디자인과 대칭되도록 프레임워크가 구성되어 있는것을 앞서 기술했다. 복잡함엔 대가가 따르기 마련이다. 엔트로피나 복잡도와 같은 주제를 앞서 다룬것은 이때문이다. 안타깝게도 모든 객체의 의존성을 관리하기 위한 수많은 원칙과 방법들을 익히는것은 OOP 신자들의 운명이다.
진화된 테스트 프레임워크는 테스트 개체간에 수많은 의존성을 부여할수 있게 되었다. 이제 DAG의 트리-순회(tree traversal)는 순차적인것과는 전혀 거리가 멀어졌다. 이는 두번째 표인 "테스트 그래프의 예"에서 순서를 보면 알수있다.
그리고 의존성이 가질수 있는 함정을 간과하고 넘어가면 안된다. 그중하나는 원형 의존성(circular dependecy)이다. 단어의 사전적 의미대로 원을 그리는 의존성을 지닌 다이어그램을 상상하면 된다. 비슷한 예는 순환 집합(Cyclic Aggregation) 관계가 있다.
집합관계는 문제가 있어보이지만 테스트 의존 관계도 같은 문제를 갖는 것일까? 상호 참조가 권장되진 않지만 논리적 오류라고 볼순 없다. 하지만 테스트의 의존 노드는 의존 대상의 결과를 선행 조건(precondition)으로 삼는 계약을 하고 있다. 이 속성때문에 원형 의존 관계는 문제가 될수있다. 물론 계약 조건을 바꿀수 있으나 그렇게 되면 테스트를 구성하는데 제약이 따르며, 테스트간 의존 관계를 부여함으로 얻어지는 이점이 상당히 떨어지게 된다. 그것은 아래의 몇가지 규칙에 연관되어있다.
테스트 DAG에 의존그래프(Dependency Graph)를 추가했을때, 트리-순회(Tree Traversal)와 실행순서에 몇가지 흥미로운 흥미로운 규칙을 발견할수 있었다.(누군가 이미 정의했을듯 하지만 아직은 본적이 없어, 신조어를 쓸수밖에 없었다.). 아래의 테스트 그래프를 보자.
* 바텀업 구조이므로 하위 테스트부터 완료후 검증해, 상위를 노드의 성공여부를 나타낸다고 생각하고 그래프를 보면 된다.
* 직선은 테스트의 트리구조를 연결하는것이고 점선과 화살표는 의존관계를 나타내는것이다.
* 원안의 번호는 트리-순회에 따라 테스트가 완료된 순서를 나타낸다.
* 원안의 번호는 트리-순회에 따라 테스트가 완료된 순서를 나타낸다.
첫번째 그래프는 의존성없이 구성된 테스트 그래프의 실행 순서이다. 그리고 두번째는 의존성은 있지만 테스트 와료 순서가 변경되지 않은 그래프, 세번째는 의존성이 있고 테스트 완료 순서가 변경된 경우이다.
두번째 그래프에서 발견할수 있는 사실은 의존성이 우에서 좌로(Right To Left) 향해있는경우, 테스트 트리-순회(Tree traversal)에 따른 테스트 실행 완료 순서가 바뀌지 않는 규칙이 있다.
반면에 세번째와 같이 의존성은 하나지만 의존성의 방향이 좌에서 우로(Left To Right) 향해있는경우, 테스트 트리-순회(Tree traversal)에 따른 테스트 완료 순서가 바뀌어 버리는것을 볼수 있다.
이제부터 이를 L2R(좌에서 우), R2L(우에서 좌)이라는 약자를 쓰겠다.
R2L를 철저히 지킨다면 의존성이 테스트 실행순서에 영향을 미칠 이유는 없다. 그러므로 의존성에 특별한 의미를 두지 않을수도 있다. 하지만 그런 디자인은 세상에 거의 없다고 봐도 된다. 불행히도 지금까지 봐온 의존성은 팔방으로 뻗었다. 즉 테스트 그래프의 실행순서는 복잡하게 얽히기 마련이다. 물론 이는 프레임워크를 만들어 놓으면 해결되니 걱정할 필요는 없다.
예전에 예를 들었던 Trent 900을 한 예를들어보겠다.(아직 이들 규칙에 모호함을 느낀다면 아래의 예를 보면된다.)
more..
2. 원형 의존의 함정
R2L만이 아니라 L2R도 존재함으로 원형 의존성은 생길수 있다. 그리고 이둘은 서로 다른 성질을 지니고 있다, 하나(R2L)는 순서를 유지시키는 것이고 다른 하나(L2R)는 순서를 바꾸는 것이다. 그리고 이 두 가지 연결의 공존은 무한 트리-순회를 초래한다.
아래는 테스트 노드가 테스트 수행을 위해 자신의 의존 노드들을 검증하는 시퀀스 다이어그램이다.
테스트 의존성 검사 시퀀스 다이어그램
현제 기술하고 있는 프레임워크는 그것의 부모 세대인 Kent Beck의 xUnit과 같은 Case & Suite에서 상속받은것이 있다. 테스트 상태 비교인 "IsTested()"와 테스트의 주 관심사인 Test() 멤버함수같은 것들이다.(xUnit은 WasRun(), Run()으로 이들을 구현하고있다.) 테스트의 상태를 저장하는것은 중복실행을 방지해줄수있기 때문에 필요하다. 중복실행을 방지한다는것은 원형 의존에 의한 무한 순회의 고리를 끊을수 있는 임시 해결책이 며 안전장치이다.1번째 Test Node : 테스트 호출 대상이며, 테스트 DAG를 트리 순회(tree-traverse)중 실행되는 테스트
2번째 Dependencies : Test Node의 의존성 컨테이너
3번째 a dependency test : 2번째 Depedencies 컨테이너가 가지고 있는 의존성 테스트
4번째 Dependencies : 3번째 test의 의존성 컨테이너
2번째 Dependencies : Test Node의 의존성 컨테이너
3번째 a dependency test : 2번째 Depedencies 컨테이너가 가지고 있는 의존성 테스트
4번째 Dependencies : 3번째 test의 의존성 컨테이너
시퀀스 다이어그램의 "1:의존성 확인" 이전에 '현제 테스트가 진행중이라면 테스트를 실패로 만드는 메소드'를 삽입하면 무한 순회는 막을수 있다. 하지만 이는 임시 방편일 뿐이다.
상호 참조, 혹 상호 대화를 하는 객체를 테스트 하는 테스트 패턴이 존재한다. 이를 셀프션트(Self Shunt)라고 하는데, 이는 모의 객체(Mock Object)와 연관이 있다. 이에 관해서는 차후에 다루겠다. 가장 좋은건 근본적인 테스트 방법 혹은 디자인을 개선하여 이를 해결해 나가는 것이다.
이 Self Shunt는 객체지향의 OCP원칙과 관련이 깊다. 객체가 확장을 허용하기 위한 추상화, 그리고 추상화 된것과의 느슨한 결합은 우리가 자주 쓰는 것들이다. 구체화 된것끼리 의존 하던 1,2 번 테스트가 모의 객체를 통해 서로 테스트 의존성을 끊고 있다. 그 모의 객체는 대화 상대를 대신하는것이며, 실체가 없는것에 의존한다는 점에서 추상화 개념과 맞물려 있다. 그리고 이것은 Flip-Flop 패턴과 유사하다.
3. 부모와 자식의 함정
상위 테스트와 하위 테스트가 포함관계에 놓이는것도 일종의 의존성 관계를 갖는것이다. 그리고 자식이 부모에 의존성을 둔다면 어떻게 될까?
'개발 > 수필' 카테고리의 다른 글
| 테스트와 장인 - 7 (0) | 2008/03/12 |
|---|---|
| 객체 지향 소프트웨어 일주 - 1 (0) | 2008/03/11 |
| 테스트와 장인 - 6 (2) | 2008/02/25 |
| 테스트와 장인 - 5 (0) | 2008/02/22 |
| 테스트와 장인 - 4 (2) | 2008/02/21 |
| 테스트와 장인 - 3 (6) | 2008/02/19 |
Trackback : http://yagur.impon.net/trackback/124
작성자: yagur Rev : 3
테스트 엔트로피(Test Entropy)
엔트로피는 모든 과학의 제 1법칙이다 - 알버트 아인슈타인(Albert Einstein)
엔트로피란 열역학에서 S로 표기되며 일로 변환할수 없는 에너지의 양을 말하며, 열역학의 통계적 무질서도를 나타낸다. 컴퓨터 과학(Computer Science)도 이 법칙으로부터 자유롭지 못하다. 컴퓨터 공학의 일부인 소프트웨어 테스트 분야 역시 이를 고스란히 상속받았다.
그렇다면 테스트 엔트로피는 어떤것에 영향을 받는것일까.
좌측은 디자인의 규모에 따른 테스트의 엔트로피 증가를 표현한 차트이다. 설계 규모가 커짐에 따라 테스트 엔트로피 역시 증가한다. 설계의 구성원의 증가에 따라 테스트 엔트로피가 비례하게 증가하는것은 어쩔수 없는 현상이다. 테스트 대상의 엔트로피와 테스트 엔트로피의 관계 역시 비슷한 모양이다.
우측은 단위 응집력과 엔트로피의 관계를 표현한 차트이다. 응집력이 낮은 단위(패키지, 컴포넌트, 클래스등) 의 디자인은 의존관계 복잡도가 높으며 그에 따른 엔트로피 역시 증가한다. 하지만 엔트로피의 감소를 위해 무조건 응집력을 높힌다면 재사용성을 감소 시킨다. 효과적인 원칙을 세우고 그 원칙을 디자인 정책으로 세운다면 응집력과 엔트로피의 트레이드 오프(trade-off)를 적절히 할수 있을것이다. 이때 도움이 되는 원칙으로는 로버트 C. 마틴의 패키지 설계 원칙이 있다. 이들은 주로 의존 관계와 재사용성에 대한 원칙들이다.(Agile Software Development - Principles, Patterns, and Practices)
응집뿐아니라 객체지향의 원칙들(SRP, OCP, LSP, DIP, ISP)들 역시 디자인 부분의 품질개선에 긍정적이다.객체간의 의존성 복잡도를 줄여준다. 테스트 프레임워크를 이루고있는 바텀업 구조를 생각해보면 부분의 개선으로 부터 시작하는것은 매우 의미 있는 일이다.
복잡도와 엔트로피의 증가를 조절해야하지만, 앞서 말한 테스트 프레임워크는 디자인의 단위 개념과 대칭 관계에 있으므로 테스트 구성의 어려움은 작다. 하지만 테스트 실행의 순서 복잡도는 디자인의 의존 관계 복잡도와 비슷해진다. 이 의존 관계 엔트로피를 감소시켜야 테스트 엔트로피 역시 감소된다.
테스트와 대상 디자인(Test and Target Design)
테스트 엔트로피를 보면 디자인 품질이 테스트 복잡도를 좌우한다. 이는 마치 미로(maze) 디자인과 도전자와의 관계와도 비슷하다. 미로가 복잡할수록 도전자는 모든 경로를 기억하며 다니기 힘들어 진다. 물론 출구 찾는 일도 힘들다.
가장 명예로운 일은 절대 넘어지지 않는 것이 아니라 넘어질 때마다 일어서는 것이다. - 공자
디자인이 나쁘다면(커다란 디자인이라고 나쁜것은 아니다) 테스트를 만들기도 힘들고, 규모가 커질수록 테스트 복잡도의 증가폭은 커진다. 이런 상황때문에 테스트를 만들수 없는 최악의 상황을 만나더라도 좌절하면 안된다, 이는 개선을 알리는 좋은 신호이다.
테스트를 통해 디자인의 품질을 가늠해 볼수도 있으며, 이는 디자인의 개선으로 이어진다. 테스트가 분석(Design Analysis)의 일부를 수행해냄을 알수있다. 비용이 큰편이지만 얻는것도 많다.
TDD같은 방법론에는 테스트 작성을 선행하고, 실체를 작성 그리고 리팩토링으로 이어진다. 어짜피 테스트를 작성해야하고, 리팩토링도 해야한다면 TDD는 매우 매력적인 방법론으로 보인다. 작성, 분석, 개선, 그리고 테스트를 전부 만족시키기 때문이다.
'장인은 도구 탓을 하지 않는다' 어떤 도구(방법론)를 사용하던 테스트와 디자인은 이루어질수 있다. 하지만 맨손으로 가꾸는 정원은 아름답기 힘들다.
'개발 > 수필' 카테고리의 다른 글
| 객체 지향 소프트웨어 일주 - 1 (0) | 2008/03/11 |
|---|---|
| 테스트와 장인 - 6 (2) | 2008/02/25 |
| 테스트와 장인 - 5 (0) | 2008/02/22 |
| 테스트와 장인 - 4 (2) | 2008/02/21 |
| 테스트와 장인 - 3 (6) | 2008/02/19 |
| 테스트와 장인 - 2 (0) | 2008/02/15 |
작성자: yagur Rev : 6
테스트 의존성과 진화(Test dependency and evolution)
동기를 얻고 주기를 알아 골격을 만들면 테스트는 객체가 될수있고, 개체로서 개발자 혹은 공동체의 재산이 될것이다. 만약 앞서 말한 테스트 골격이 만들어질경우, 테스트가 계층을 위한 방향성 비순환 그래프(DAG)를 이루게 된다. 그렇다면 일단 JUnit이나 UnitTest++과 같은 프레임워크들과는 다른 형태로 진화된 것이다. Case & Suite의 형태보다 체계적(계층적)으로 진화 되었지만 여기서 멈추면 그 의미가 퇴색된다.
이제는 우리의 선조인 아칸소스테가가 치열해진 환경으로 부터 살아남기 위해 지느러미를 손으로 진화시킨것처럼, 테스트 프레임워크 역시 복잡해지고 거대해진 테스트 집합에 적응하기 위해 유한하며, 대칭적이고, 재귀적인 의존성 그래프(Dependency Graph)란 도약을 해야 한다.
그리고 여기서 말하는 의존성이 대체 무엇일까? 객체사이의 의존 관계와 비슷하며, 사전적 의미를 생각하면 된다. 특정 테스트를 진행하기 위한 선행 조건은 의존 관계를 맺고 있는 테스트의 성공 여부가 될수있다. 이 의존성은 간단한 원리이지만, 인터넷상에 공개되어있는 Case & Suite형의 1세대 테스트 프레임워크는 이를 지원하지 않고, 의존성에 상관없이 모든 테스트를 진행한다. 어쩔수 없다 태생이 리스트이며 행위가 절차적이다. 하지만 이들은 매우 간단한 프로세스를 가지고 있다는 장점이 있다. 그리고 비록 말장난이 섞여 있지만 마틴 파울러는 이 간결함에 대해 아래와 같이 찬사했다.
" 소프트웨어 공학 역사에서 이토록 많은 사람이 이렇게 짧은 코드로 이토록 큰 은혜를 입은 적이 없었다. "
의존성을 실제로 다른것들도 가지고 있는지 궁금할 수도 있다. 이미 그 예는 앞에서 보았다. 롤스로이스가 자동차와 비행기 방면에 장인이라 불리우며 그것을 입증한 그들의 테스트 세트를 말하는것이다. 부분의 품질을 검증해 집합의 품질을 보장하는 바텀업 구조에 이 의존성이 깔려있다. 아래의 다이어그램은 의존도를 보여주고있다.
테스트 의존도 다이어그램의 예
이들은 Fan Blade Test를 통과하지 않고 Fan Test, Engine Test를 진행하지 않을것이다. 좀 극단적인 예이지만 엔진이 돌아가지 않는데 비행기를 띄울것인가? 당연한 이치이고 우리는 이미 이 관계를 인식하고 있지만, 안타깝게도 진화가 덜된 테스트 프레임워크는 육지로 도약할수 없다. (그리고 롤스로이스는 쓸대 없는 비용을 낭비하기 원치 않는다. 팬 블레이드 하나의 가격은 최고급 승용차 값이라 한다. 의존성의 역활은 논리적으로 간단하고 프로세스에 명시하지 않아도 들어가야한다.)
그들이 연구 분석과 회귀 테스트를 통해 얻어낸 가볍고 단단함을 위한 티타늄 선택, 900도의 열처리등은 모두 이 과정의 산물이다. 테스트 계약 조건을 통과하더여 의존성을 만족해 상위 테스트가 진행된다 해도 실패할 경우 하위 테스트의 조건이 변하고 그 테스트는 진화한다. 그리고 제품의 질은 향상된다. 이는 테스트의 의존성과 테스트 세트의 진화, 그리고 제품의 품질 향상이 밀접하게 연관되어 있음을 알수있는 부분이다.
시스템 테스트가 하위 컴포넌트 테스트인 엔진테스트에 어떤 영향을 끼쳤는지 알아보자. 일단 엔진테스트를 통과하여 비행기는 순조롭게 운항되었다. 하지만 좌측과 같은 생각지 못한 상황이 생긴다. 그래서 우측과 같은 테스트가 엔진 테스트 셋에 추가되었다.
과거 보잉 747은 좌측과 같은 문제를 안고 있었다. 팬 블레이드가 새와충돌했을때 견디는지, 또 새가 엔진으로 삽입되었을때 엔진이 버티는지에 대하여, 롤스로이스는 일명 "새 투입"(Bird Injection)이란 테스트 추가하며 테스트 셋을 확장시킴과 동시에 제품의 품질도 향상 시켰다.
소프트웨어도 거의 같은 의존성과 주기를 가지고 있다. 생성자의 결과가 테스트를 통과하지 못했는데 그 클래스로 무슨 테스트를 진행할것 인지 생각해봐야한다. 또한 실패한 테스트 결과를 가진 단위를 이용한 테스트 집합 일부가 성공한다면 그 일부를 신뢰할수 있는지도 생각해봐야한다. 아마 둘다 신뢰할수 없을것이다. 또 하드 디스크에 42기가의 데이터를 적는 테스트라고 가정해보자, 초기 1메가 기록중 잘못된 기록이라 판별되었을때 나머지 41999메가를 적기를 기다렸다가, 오류를 고칠것인가? 이것은 시간과 효율성에도 연관이 있다.
하지만 의존성과 하위 테스트는 분리되어 운영되어야 한다. 의존성은 계약 조건의 역활을 갖는 노드이고 하위테스트는 자식 테스트로서의 역활을 가지고 있다. 각 테스트 브랜치(혹은 노드)는 의존성과 자식을 동시에 지닐수 있어야 복잡한 의존관계를 성공적으로 제어할수 있게 될것이다.
테스트의 복잡도(Complexity of Tests)
밑에는 테스트 객체들간의 연관성을 나타내는 연관 복잡도를 나타내는 다이어그램이다.
테스트 객체간의 연관 다이어그램
난 이 다이어그램을 작성하고 거미줄을 그리고 있는지 알았다. 그만큼 서로의 연관 복잡도는 높지만, 이미 우리는 이것이 복잡한것이 아니라 간단한 계층 구조와 의존관계에 때문이라는것을 알고 있다. 개념은 간단하지만 상호작용이 많다. 다음에 설명하겠지만 패턴을 활용한 클래스 계층 구조는 이렇게 복잡하지 않다. 상호작용에 따라 다이어그램이 복잡해 보일뿐이다. 아마 독자중 일부는 이미 눈치 챘을것이다. 추상화 한것에 의존해 느슨한 결합으로 이 연관관계를 단순화 시키는 것 말이다. 설계상 해법은 그렇지만 다형성을 활용한다 해도 실체간의 연관관계는 거미줄같다.
테스트가 대형화 될수록 가속되는 복잡도의 변화는 어떨지 생각해보자. 다행히 위의 객체간 연관 복잡도는 변하지 않는다. 물론 테스트 유형을 추가하면 복잡도는 증가할것이다. 하지만 테스트 개체 브랜치(노드)의 수는 소프트웨어 디자인과 거의 대칭된다. 아마 가장 낮은 단위의 브랜치인 클래스 테스트가 가지는 리프 테스트(Leaf test)인 유닛테스트까지 합친다면 그 수가 상당히 많아진다. 즉 테스트 개체 복잡도는 대형화되는 속도에 비례해 증가한다. 하지만 걱정할것 없다 각 테스트 브랜치(노드)를 때어 놓고 보면 그 복잡도는 작다. 잘 관리하고 문서화한다면 복잡도는 쉽게 제어할수 있는 수준이다.
문서화는 대형화된 테스트의 필수적인 요소이며, 테스트 작성과 동시에 이루어지는것이 좋다. 하지만 정보의 중복이 일어나는것(DRY 원칙)에 조금 불편함을 느낄수도 있다. (테스트 프레임워크는 의존성을 포함한 개체 복잡도를 이미 알고있다).
이럴땐 합리적인 비용비교를 해볼수 있다. 매번 테스트 작성때마다 문서를 변경할것인가? 아니면 개체 복잡도를 리포트로 출력하는 모듈을 만들것인가. 이전에 언급했던 MVC의 View에 이 모듈을 추가해 자동화 할수 있다. 어느쪽이든 합리적인 선택을 하기 바란다.
테스트 의존성과 진화(Test dependency and evolution)
아는 것으로 충분치 않다. 그것을 적용해야 한다. 하고자 함으로 충분치 않다. 실제로 행해야 한다.
- 요한 볼프강 폰 괴태
동기를 얻고 주기를 알아 골격을 만들면 테스트는 객체가 될수있고, 개체로서 개발자 혹은 공동체의 재산이 될것이다. 만약 앞서 말한 테스트 골격이 만들어질경우, 테스트가 계층을 위한 방향성 비순환 그래프(DAG)를 이루게 된다. 그렇다면 일단 JUnit이나 UnitTest++과 같은 프레임워크들과는 다른 형태로 진화된 것이다. Case & Suite의 형태보다 체계적(계층적)으로 진화 되었지만 여기서 멈추면 그 의미가 퇴색된다.
이제는 우리의 선조인 아칸소스테가가 치열해진 환경으로 부터 살아남기 위해 지느러미를 손으로 진화시킨것처럼, 테스트 프레임워크 역시 복잡해지고 거대해진 테스트 집합에 적응하기 위해 유한하며, 대칭적이고, 재귀적인 의존성 그래프(Dependency Graph)란 도약을 해야 한다.
그리고 여기서 말하는 의존성이 대체 무엇일까? 객체사이의 의존 관계와 비슷하며, 사전적 의미를 생각하면 된다. 특정 테스트를 진행하기 위한 선행 조건은 의존 관계를 맺고 있는 테스트의 성공 여부가 될수있다. 이 의존성은 간단한 원리이지만, 인터넷상에 공개되어있는 Case & Suite형의 1세대 테스트 프레임워크는 이를 지원하지 않고, 의존성에 상관없이 모든 테스트를 진행한다. 어쩔수 없다 태생이 리스트이며 행위가 절차적이다. 하지만 이들은 매우 간단한 프로세스를 가지고 있다는 장점이 있다. 그리고 비록 말장난이 섞여 있지만 마틴 파울러는 이 간결함에 대해 아래와 같이 찬사했다.
" 소프트웨어 공학 역사에서 이토록 많은 사람이 이렇게 짧은 코드로 이토록 큰 은혜를 입은 적이 없었다. "
-마틴 파울러
의존성을 실제로 다른것들도 가지고 있는지 궁금할 수도 있다. 이미 그 예는 앞에서 보았다. 롤스로이스가 자동차와 비행기 방면에 장인이라 불리우며 그것을 입증한 그들의 테스트 세트를 말하는것이다. 부분의 품질을 검증해 집합의 품질을 보장하는 바텀업 구조에 이 의존성이 깔려있다. 아래의 다이어그램은 의존도를 보여주고있다.
테스트 의존도 다이어그램의 예
그들이 연구 분석과 회귀 테스트를 통해 얻어낸 가볍고 단단함을 위한 티타늄 선택, 900도의 열처리등은 모두 이 과정의 산물이다. 테스트 계약 조건을 통과하더여 의존성을 만족해 상위 테스트가 진행된다 해도 실패할 경우 하위 테스트의 조건이 변하고 그 테스트는 진화한다. 그리고 제품의 질은 향상된다. 이는 테스트의 의존성과 테스트 세트의 진화, 그리고 제품의 품질 향상이 밀접하게 연관되어 있음을 알수있는 부분이다.
시스템 테스트가 하위 컴포넌트 테스트인 엔진테스트에 어떤 영향을 끼쳤는지 알아보자. 일단 엔진테스트를 통과하여 비행기는 순조롭게 운항되었다. 하지만 좌측과 같은 생각지 못한 상황이 생긴다. 그래서 우측과 같은 테스트가 엔진 테스트 셋에 추가되었다.
소프트웨어도 거의 같은 의존성과 주기를 가지고 있다. 생성자의 결과가 테스트를 통과하지 못했는데 그 클래스로 무슨 테스트를 진행할것 인지 생각해봐야한다. 또한 실패한 테스트 결과를 가진 단위를 이용한 테스트 집합 일부가 성공한다면 그 일부를 신뢰할수 있는지도 생각해봐야한다. 아마 둘다 신뢰할수 없을것이다. 또 하드 디스크에 42기가의 데이터를 적는 테스트라고 가정해보자, 초기 1메가 기록중 잘못된 기록이라 판별되었을때 나머지 41999메가를 적기를 기다렸다가, 오류를 고칠것인가? 이것은 시간과 효율성에도 연관이 있다.
하지만 의존성과 하위 테스트는 분리되어 운영되어야 한다. 의존성은 계약 조건의 역활을 갖는 노드이고 하위테스트는 자식 테스트로서의 역활을 가지고 있다. 각 테스트 브랜치(혹은 노드)는 의존성과 자식을 동시에 지닐수 있어야 복잡한 의존관계를 성공적으로 제어할수 있게 될것이다.
테스트의 복잡도(Complexity of Tests)
복잡도는 줄일수 없다. 단지 간결함의 허상을 만들수 있을뿐이다 - Grady Booch
밑에는 테스트 객체들간의 연관성을 나타내는 연관 복잡도를 나타내는 다이어그램이다.
난 이 다이어그램을 작성하고 거미줄을 그리고 있는지 알았다. 그만큼 서로의 연관 복잡도는 높지만, 이미 우리는 이것이 복잡한것이 아니라 간단한 계층 구조와 의존관계에 때문이라는것을 알고 있다. 개념은 간단하지만 상호작용이 많다. 다음에 설명하겠지만 패턴을 활용한 클래스 계층 구조는 이렇게 복잡하지 않다. 상호작용에 따라 다이어그램이 복잡해 보일뿐이다. 아마 독자중 일부는 이미 눈치 챘을것이다. 추상화 한것에 의존해 느슨한 결합으로 이 연관관계를 단순화 시키는 것 말이다. 설계상 해법은 그렇지만 다형성을 활용한다 해도 실체간의 연관관계는 거미줄같다.
테스트가 대형화 될수록 가속되는 복잡도의 변화는 어떨지 생각해보자. 다행히 위의 객체간 연관 복잡도는 변하지 않는다. 물론 테스트 유형을 추가하면 복잡도는 증가할것이다. 하지만 테스트 개체 브랜치(노드)의 수는 소프트웨어 디자인과 거의 대칭된다. 아마 가장 낮은 단위의 브랜치인 클래스 테스트가 가지는 리프 테스트(Leaf test)인 유닛테스트까지 합친다면 그 수가 상당히 많아진다. 즉 테스트 개체 복잡도는 대형화되는 속도에 비례해 증가한다. 하지만 걱정할것 없다 각 테스트 브랜치(노드)를 때어 놓고 보면 그 복잡도는 작다. 잘 관리하고 문서화한다면 복잡도는 쉽게 제어할수 있는 수준이다.
아무리 흐린 먹물이라도 가장 훌륭한 기억력보다 낫다. - 중국 속담
문서화는 대형화된 테스트의 필수적인 요소이며, 테스트 작성과 동시에 이루어지는것이 좋다. 하지만 정보의 중복이 일어나는것(DRY 원칙)에 조금 불편함을 느낄수도 있다. (테스트 프레임워크는 의존성을 포함한 개체 복잡도를 이미 알고있다).
생각 없이 행할 수 있는 중요한 작업의 수가 늘어남에 따라 문명은 발전한다.
- 알프레드 노스 화이트헤드
이럴땐 합리적인 비용비교를 해볼수 있다. 매번 테스트 작성때마다 문서를 변경할것인가? 아니면 개체 복잡도를 리포트로 출력하는 모듈을 만들것인가. 이전에 언급했던 MVC의 View에 이 모듈을 추가해 자동화 할수 있다. 어느쪽이든 합리적인 선택을 하기 바란다.
'개발 > 수필' 카테고리의 다른 글
| 테스트와 장인 - 6 (2) | 2008/02/25 |
|---|---|
| 테스트와 장인 - 5 (0) | 2008/02/22 |
| 테스트와 장인 - 4 (2) | 2008/02/21 |
| 테스트와 장인 - 3 (6) | 2008/02/19 |
| 테스트와 장인 - 2 (0) | 2008/02/15 |
| 테스트와 장인 - 1 (2) | 2008/02/14 |
Trackback : http://yagur.impon.net/trackback/122
작성자: yagur Rev : 2
테스트 집합 그리고 재사용성(Test-sets and Reusability)
동기와 주기는 윤곽이 조금 잡혔지만 테스트 구조는 비행기에 관한것이었다. 소프트웨어의 그것과 닮아있지만 소프트웨어는 실체를 가진것이 아닌 디스크에 쓰여있는 논리 덩어리들이다. 논리를 검증하는것과 비행기를 검증하는것의 차이는 개념상으론 백지창 차이지만 실천의 관점으로 봐서는 천지차이라고 생각할수도 있다.
하지만 테스트 집합의 영역을 명확히 한다면 실천 방법의 도구인 테스트 프레임워크를 작성하는것은 한층 수월해질것이다. 이 테스트 프레임워크 역시 사용처에 따라 수없이 재사용 되고 진화될 컴포넌트이다.
테스트 프레임워크의 진화는 제품의 품질향상과도 연관이 있다. 앞서 예로 들었던 트렌트 900의 테스트 프레임 워크와 테스트 세트(test set)를 재용하여 그들은 트렌트 1000이란 제품을 만들어 낼수 있었다. 물론 사용자 요구사항을 맞추기 위해 일부 항목은 진화됬을것이다. 그리고 트렌트 1000은 보잉 787기에 채용되었다. 소프트웨어의 버젼업과 유사하다.
훌륭한 테스트 프레임워크가 없이 새 제품을 만들어 낼수 있었을까? 전문성을 지닌 지성 집단이 고안하고 진화시킨 테스트 프레임워크는 롤스로이스사의 최대 공헌자이며 재산이다. 이것이 없이는 새제품의 개선을 이루어 내는 비용은 상상하기 힘들기 때문이다. 실제로 trent 1000의 테스트 과정을 담은 영상은 trent 900의 그것과 다를것이 없었다.[링크]
비행기나 엔진, 혹은 소프트웨어는 부분의 품질을 보장해 나간다. 그리고 부분들의 집합 품질을 보장해 나간다. 이른바 통합, 회귀 테스트들은 훌륭한 과정이 되어주는 셈이다.
테스트 골격(Test framework)
테스트의 과정을 이루는 부분에서 집합으로 품질을 보장시켜나가는 바텀업(bottom-up) 구조는 유용한 테스트 프레임워크의 구조가 될수있다. 이들 테스트들을 몇가지 명칭들이 있는데 이들은 통합 모델링 언어(UML)에서 사용되는것과 크게 다르지 않다. 사용자가 추상적인 단위를 비슷 하게 인식하기 때문이다.
System Test, Component Test, Unit Test같은 스위트(suite)와 케이스(case)들은 모델링 단위별 검증을 위한것이다. 그리고 자체 검증외적으로 부하, 스트레스, 침수와 같은 환경 변화에 따른 테스트들이 존재하며, 사용자를 위한 사용성 테스트 같은것도 존재한다.
테스트들을 Case와 Suite로 일반화해 사용할수도 있고, 위와 같이 명시적인 단위로 나누어 프레임워크를 구성할수도 있다. 명시적인 것의 장점은 테스트 관점에서 볼때 단위 분리가 일어나는 것이다. 이것은 체계적인 오류 검출의 좋은 시작 포인트가 될수 있다.
예를 들자면 아래의 두가지 테스트 리포트로 예를 들어보자.
1> "XXX 테스트 스위트의 XXX 테스트 케이스에 오류."
2> "XXX System / XXX Component / XXX Class / XXX Method UnitTest의 오류."
2번이 좀더 객관적이고 체계적인 느낌을 받을수 있다. 이는 테스트와 디자인(설계)이 1:1 매칭 관계를 이루고 있기때문에 상당히 직관적이기 때문이다. 또한 이 계층적 테스트는 그래프로서 표현하기도 쉽다. 이 계층은 방향성 비순환 그래프(Direct Acyclic Graph)로 표현될수도 있으며 구조적으로 GoF's Composite Pattern, 행위면에선 GoF's Observer Pattern을 이용한다면 조금더 좋은 형태의 프레임워크가 될수 있을것이다.
테스트 트리의 예
어떤 방식을 사용하던 도구에 불과하니 테스트의 본질을 간과하지는 않는다. 테스트 프레임워크를 구성하고 작성된 테스트가 연속된 통합(continuous integration)의 일부가 된다면 이는 성공적인 사례를 만든 것이다.
좀더 진보시켜 테스트 프레임워크에 MVC를 적용할수도 있다. 테스트 모델, 뷰, 컨트롤로 나누는것인데 모델은 테스트, 뷰는 테스트 리포트의 출력방식(Text, Html, XML...), 컨트롤은 모델별 테스트에 부가적인 요소(환경,스트레스 테스트)들의 실행여부 등 여러가지에 활용할수 있다.
이쯤 되면 테스트 프레임워크는 작은 하나의 소프트웨어만큼의 복잡도를 띄게 된다. 하지만 이는 검증과 자동화를 위한 훌륭한 도구가 될것이다.
소프트웨어 안의 객체들 사이의 의존성에 따른 복잡도는 대부분 머리 아플정도이다. 그들의 테스트를 다뤄야할 도구이기 때문에 편리성이나 자동화는 좀더 실용적인 측면에서 강조하게 될수 밖에 없다. 지금 나와있는 훌륭한 오픈소스 프레임워크들을 활용하는것도 좋은 방법이지만 그 기능은 진화 시켜 사용하는것이 좋다고 보여진다.
테스트 집합 그리고 재사용성(Test-sets and Reusability)
동기와 주기는 윤곽이 조금 잡혔지만 테스트 구조는 비행기에 관한것이었다. 소프트웨어의 그것과 닮아있지만 소프트웨어는 실체를 가진것이 아닌 디스크에 쓰여있는 논리 덩어리들이다. 논리를 검증하는것과 비행기를 검증하는것의 차이는 개념상으론 백지창 차이지만 실천의 관점으로 봐서는 천지차이라고 생각할수도 있다.
테스트 프레임워크의 진화는 제품의 품질향상과도 연관이 있다. 앞서 예로 들었던 트렌트 900의 테스트 프레임 워크와 테스트 세트(test set)를 재용하여 그들은 트렌트 1000이란 제품을 만들어 낼수 있었다. 물론 사용자 요구사항을 맞추기 위해 일부 항목은 진화됬을것이다. 그리고 트렌트 1000은 보잉 787기에 채용되었다. 소프트웨어의 버젼업과 유사하다.
훌륭한 테스트 프레임워크가 없이 새 제품을 만들어 낼수 있었을까? 전문성을 지닌 지성 집단이 고안하고 진화시킨 테스트 프레임워크는 롤스로이스사의 최대 공헌자이며 재산이다. 이것이 없이는 새제품의 개선을 이루어 내는 비용은 상상하기 힘들기 때문이다. 실제로 trent 1000의 테스트 과정을 담은 영상은 trent 900의 그것과 다를것이 없었다.[링크]
비행기나 엔진, 혹은 소프트웨어는 부분의 품질을 보장해 나간다. 그리고 부분들의 집합 품질을 보장해 나간다. 이른바 통합, 회귀 테스트들은 훌륭한 과정이 되어주는 셈이다.
테스트 골격(Test framework)
테스트의 과정을 이루는 부분에서 집합으로 품질을 보장시켜나가는 바텀업(bottom-up) 구조는 유용한 테스트 프레임워크의 구조가 될수있다. 이들 테스트들을 몇가지 명칭들이 있는데 이들은 통합 모델링 언어(UML)에서 사용되는것과 크게 다르지 않다. 사용자가 추상적인 단위를 비슷 하게 인식하기 때문이다.
System Test, Component Test, Unit Test같은 스위트(suite)와 케이스(case)들은 모델링 단위별 검증을 위한것이다. 그리고 자체 검증외적으로 부하, 스트레스, 침수와 같은 환경 변화에 따른 테스트들이 존재하며, 사용자를 위한 사용성 테스트 같은것도 존재한다.
테스트들을 Case와 Suite로 일반화해 사용할수도 있고, 위와 같이 명시적인 단위로 나누어 프레임워크를 구성할수도 있다. 명시적인 것의 장점은 테스트 관점에서 볼때 단위 분리가 일어나는 것이다. 이것은 체계적인 오류 검출의 좋은 시작 포인트가 될수 있다.
예를 들자면 아래의 두가지 테스트 리포트로 예를 들어보자.
1> "XXX 테스트 스위트의 XXX 테스트 케이스에 오류."
2> "XXX System / XXX Component / XXX Class / XXX Method UnitTest의 오류."
2번이 좀더 객관적이고 체계적인 느낌을 받을수 있다. 이는 테스트와 디자인(설계)이 1:1 매칭 관계를 이루고 있기때문에 상당히 직관적이기 때문이다. 또한 이 계층적 테스트는 그래프로서 표현하기도 쉽다. 이 계층은 방향성 비순환 그래프(Direct Acyclic Graph)로 표현될수도 있으며 구조적으로 GoF's Composite Pattern, 행위면에선 GoF's Observer Pattern을 이용한다면 조금더 좋은 형태의 프레임워크가 될수 있을것이다.
어떤 방식을 사용하던 도구에 불과하니 테스트의 본질을 간과하지는 않는다. 테스트 프레임워크를 구성하고 작성된 테스트가 연속된 통합(continuous integration)의 일부가 된다면 이는 성공적인 사례를 만든 것이다.
좀더 진보시켜 테스트 프레임워크에 MVC를 적용할수도 있다. 테스트 모델, 뷰, 컨트롤로 나누는것인데 모델은 테스트, 뷰는 테스트 리포트의 출력방식(Text, Html, XML...), 컨트롤은 모델별 테스트에 부가적인 요소(환경,스트레스 테스트)들의 실행여부 등 여러가지에 활용할수 있다.
이쯤 되면 테스트 프레임워크는 작은 하나의 소프트웨어만큼의 복잡도를 띄게 된다. 하지만 이는 검증과 자동화를 위한 훌륭한 도구가 될것이다.
소프트웨어 안의 객체들 사이의 의존성에 따른 복잡도는 대부분 머리 아플정도이다. 그들의 테스트를 다뤄야할 도구이기 때문에 편리성이나 자동화는 좀더 실용적인 측면에서 강조하게 될수 밖에 없다. 지금 나와있는 훌륭한 오픈소스 프레임워크들을 활용하는것도 좋은 방법이지만 그 기능은 진화 시켜 사용하는것이 좋다고 보여진다.
'개발 > 수필' 카테고리의 다른 글
| 테스트와 장인 - 5 (0) | 2008/02/22 |
|---|---|
| 테스트와 장인 - 4 (2) | 2008/02/21 |
| 테스트와 장인 - 3 (6) | 2008/02/19 |
| 테스트와 장인 - 2 (0) | 2008/02/15 |
| 테스트와 장인 - 1 (2) | 2008/02/14 |
| AOP와 직교성, 그들의 도구로 RAII와 Proxy의 활용 (0) | 2008/02/12 |
-
ProgC 2008/02/20 13:42
작성하신 글을 매우 흥미롭게 읽었습니다.(1,2,3편 모두 읽었는데 다음편도 있는건가요?) ^^ 확실히 저는 만들기만 했지 만들어진 제품의 품질에 대한 생각은 거의 해보지 않았던것 같습니다. 덕분에 제작자 입장에서 신뢰라는 것을 어떻게 만들어 낼 수 있는지 생각해 보게 되는 계기가 되었습니다. 감사합니다. ^^
여담이지만... 테스트 프레임워크는 어쩔 수 없이 기술적인 테스트만을 할 수 밖에 없다고 봅니다. 왜냐하면 아쉽게도... 게임과 같은 경우에는 재미있다. 없다의 기준이 없기 때문이죠. 그래서 저희 회사도... 수작업(?)으로 QA들이 게임을 합니다. 매일;;;;-
yagur 2008/02/20 16:39
ProcC님의 블로그를 종종 들려 좋은 글들 잘보고있습니다. 저도 동의합니다. 기술, 무결성, 그리고 디자인을 검증, 검토하거나 방법론에 따라서는 개발을 주도하기 위해 테스트가 주로 쓰이고 있다는데에 동의합니다.
QA팀이 재미란 요소를 그렇게 매일 테스트하는군요. 역시 세계에 통하는 기업이란 생각이 듭니다. 일종의 유저빌리티 테스트 주기가 매일 일어난다는 점에서 상당히 팀원들에겐 고무적일것 같습니다. 저 피드백이 자주 일어나는 것은 회귀 테스트가 자주 일어나는 것이고, 그 주기가 매일인점은 기업의 개발 공정이 능동적이며 튼튼하다고 생각하여 부러워 하고 있습니다 =)
-
-
황상철 2008/02/20 14:21
첫번째 그림의 테스트유형간의 그림에서 Aggregation으로 표현하는것은 논란의 여지가 있을듯 합니다. 차라리 그냥 relationship이 있다 정도로 표현하는게 더 좋지 않을까..아니면 관계의 의미를 명확히 하기 위해 관계명을 써주는것도..암튼 좋은글 잘 읽었습니다.
-
좋은 지적 감사드립니다. 제가 UML을 남을 위해 작성한적이 없어 생긴 미숙함인것 같습니다. 제 프레임워크를 생각하며 다이어그램을 만들어 그랬던것 같습니다. 제 표현에도 모호성이 있었고 일반적이지 않은 다이어그램이라 의미전달이 부족했던것 같습니다. 그리고 마틴 파울러는 Aggregation을 "Aggregation is the part-of relationship"이라고 하고잇습니다. Relationship이지만 조금 구체적인 관계를 표현하기 위해 Composition이나 Association이 아닌 Aggregation을 선택 했습니다. 간단한 표기를 위해 스테레오 타입을 생략했는데 이것도 모호성에 한몫했었던걸까요.
마틴 파울러의 UML Distilled에서 보던 Association과 Aggregation 사이의 모호성에 대한것을 현실에서 이야기할수 있게 되어 정말 기쁩니다. 로버트 C 마틴도 이 모호성 때문에 Aggregation UML 표기를 잘 하지 않는다고 합니다. UML에도 명확한 정의가 없다는 이유도 들고있습니다. Association과 스테레오 타입을 표기하는게 더 좋다는 판단을 하고있는것으로 보입니다.
그런데 전 Composite Pattern으로 DAG를 실체화 시키려 하였고 그 GoF의 해당 패턴 다이어그램에 Component와 Composite사이를 집합 관계로 표현하고 있다는점, 또 Composition과 달리 생명주기가 다르다는점에서 Aggregation으로 표현하였습니다. 하지만 Composite Pattern을 사용한다 했으나 Component와 Composite는 추상적인 것이라 다이어그램으로 나타내지 않고, Leaf나 Branch의 관계만 다이어그램으로 나타냈습니다. (제 실수입니다.)
GoF의 책에 Association과 Aggregation의 차이를 결합도의 차이로 보고있군요. 물론 이는 그들의 관점입니다. 명확하지 않은 표기법에 대한 그들의 해석인것 같습니다.
책의 인용 : "참조자 관리는 한 객체가 다른 객체에 대해 알고 있음을 의미한다. 우리는 이를 연결 관계 (Association)또는 사용 관계라고 말한다. 참조 객체는 다른 객체의 오퍼레이션을 요청할 수도 있지만 책임은 지지 않는다. 참조 관계는 집합 관계보다 약한 관련성을 가지고 있어 객체들 간의 약한 결합도를 갖게 한다."
그리고 이들이 참조 관계가 아닌 집합 관계가 될수 있다는것은 Component Test와 System Test, Integration Test 같은 경우 Code Craft나 Code Complete와 같은 책을 참고하였습니다. 이 테스트들을 하위 테스트들의 모임으로 설명하고 있기때문입니다. 통합 테스트 역시 통합 대상의 집합으로 생각해 그리 하였습니다. 그들이 중복 참조 될수 있다는 점에서 DAG를 선택하였습니다.
추상적인 사람의 생각을 다이어그램으로 표현하려니 보는 사람마다 좀 다른 해석을 할수 있군요. 앞으로 더 정진해야겠습니다. 부족한 글 읽어주시고 평까지 해주셔서 감사합니다.
-
-
모델링의 Notation은 그리 중요하다고 생각하지 않는 사람입니다. 사실 UML 2.0에서 Aggregation과 Composition의 구분이 없어진것처럼 모델링에서 사람이 모호함을 느끼는 부분은 오히려 단순화 하는게 맞다고 생각합니다. 제가 저 위의 다이어그램을 보고 모호함을 느낀부분은 테스트 간에 포함관계나 라이프사이클이 나타날수 없다고 생각하는데 그렇게 표현하신듯 하여 관계가 모호하다 이야기 했습니다. 현장에서 모델링을 가이드 하다 보면 많은 사람들이 제대로 자기가 생각하는 바를 표현 못하는걸 봤습니다. 그럴때 마다 Notaiton을 차이를 설명하기 보다는 명확한 방법은 제시하는 편입니다. "차라리 주석을 달아라." 암튼 4번째 테스트와 장인 기대하겠습니다.
-
좀더 명확한 다이어그램의 중요성을 느끼게 됬습니다. 계층 구조의 다이어그램이라기 보다 포함 관계를 러프하게 표현하려다 보니 표기법의 속성이 다 들어나지 못하고 모호성으로 이어진것 같습니다. 표기법 속성에 관해 미리 명시하는 책들, 혹은 명명법을 미리 명시하는 책들의 배려를 보고 저의 잘못을 회고해 봐야겠습니다.
"잘못 사용될 가능성이 있는것은 잘못 사용되고야 만다"는 머피의 법칙을 느껴봅니다. 유익한 대화였습니다. 즐거운 하루되세요 황상철님.
-
Trackback : http://yagur.impon.net/trackback/121
작성자: yagur Rev : 2
주기적 테스트(Cyclic Test)
" 새로운 버그가 발견될 때마다 프로그램 유지 보수를 위해서 각 상태 별로 더 많은 시스템 테스트가 필요하게 된다. 이론적으로 예기치 않은 문제의 발생을 방지하기 위해서 각각의 버그 픽스 후에는 반드시 이전에 실행했던 전체 배치 테스트를 수행해야한다. 그러나 실제로 이런 회귀 테스트는 이론에나 부합되는 굉장한 아이디어긴 하지만 상당한 비용을 지불해야 된다는 것을 깨닫게 된다."
- 프레더릭 브룩스(The mythical man-month)
테스트는 주기적으로 이루어지며 회귀(regression)와 통합(integration)으로 볼수있다. 부분(단위) 품질을 검증하기 위한 테스트, 혹은 테스트 우선을 통해 만들어진 결과물들은 모두 회귀 테스트가 될수있다. TAD라면 부분을 만들어 놓고 테스트를 하여 검증하고 개선을 할테고, TDD라면 부분에 관한 테스트를 만들면서 대상이 완성될것이다. 그리고 이 테스트는 회귀테스트용으로 쓰일수 있다. 시험 대상에 오류가 있을때 와서 시도 할수 있고, 오류에 관한 테스트를 추가하면서 테스트 셋이 진화될것이다.
앞에서 본것 같이 오류나 외부환경에 대한 테스트들을 통과한 집합체가 모였을때, 연동이 잘되는지 보기 위해 통합테스트를 한다. 회귀와 통합은 땔수 없는 관계에 있다. 이 통합 또한 회귀되기 때문이다.
통합테스트는 코드로 표현되지만 회귀는 사람이나 개발 시스템이 하는 행위에 가깝다. 하지만 두가지 모두 다 텀이 다를뿐 주기적으로 이루어진다.
트렌트 900 역시 비슷했을 것이다.
(1) 부품별 테스트, 그리고 회귀 <ex: 팬의 날>
(2) 부분들의 통합테스트 그리고 회귀 < ex: 팬과 모터 >
(3) 부하, 스트레스, 침수 테스트 그리고 회귀 <ex: 트렌트 900의 물, 모래 테스트 >
1번은 클래스의 유닛테스트와 유사해 보이고, 2번은 한 컴포넌트안에 클래스들의 통합테스트로 비교할수 있으며, 3번은 스트레스 테스트를 통해 1,2번의 회귀를 제공해 개선과 진화를 일으킨다. 소프트웨어 테스트와 상당히 닮아있다. 3번을 만족한다면 시스템 테스트로 이어질 조건이 만족되는 것이다.
이 주기들을 거쳐 최종적으로 이루어지는 시스템 테스트는 어떤 모양을 가졌을지 궁금할것이다. A380이란 비행기 시스템과 트렌트 900이란 컴포넌트는 시스템 테스트에 어떻게 참여될까.
보기에도 참 많은 테스트를 했다. Iceland에서 옆바람 테스트, 프랑스에서 엔진 침수 테스트, 캐나다에서 저온 테스트, 고온 테스트, 콜롬비아에서 고도 테스트, 항로 성능시험등 비행시간으로 2710시간이고 820회 비행, 테이크오프는 무려 1855회를 하여 지구의 약 70바퀴거리를 운행했다. 컴포넌트 테스트가 시스템테스트에 포함된것을 볼수 있다.
긴 시간동안에 다양한 스트레스와 부하를 통해 트렌트 900은 비행기란 시스템을 안전하게 운행시켰다. 이제 녹색 막대가 여러개 보일것 이다. 마지막에 Marion C Blackey란 비행 협회 행정관은 A380의 비행능력을 인증해준다.
이것이 우리 소프트웨어라면 어떨까? 총 240시간의 서버 스트레스 테스트와 총 720시간의 연속 렌더링 시험을수 차례 거처 최종 결과물이 안정적으로 전시회에 전시되어 호평을 받는것을 상상해 볼수있다. 테스트 비용은 생각보다 크다. 그러나 좀더 안정적이다.
테스트가 없다면? 전시회 전날까지 그 동안의 개발과 변경이 전시회에서 어떤 성능을 발휘할지 그저 그동안의 경험과 노력 그리고 실패 하지 않은 빌드를 믿을수 밖에 없다.
리팩토링 비용이 크다고 하지 않는가? 그것은 리팩토링을 미루어 왔기 때문이다. 테스트도 마찬가지이다. 테스트 비용이 크다고 하지 않는가? 그것은 테스트를 미루어 왔기 때문이다.
'개발 > 수필' 카테고리의 다른 글
| 테스트와 장인 - 4 (2) | 2008/02/21 |
|---|---|
| 테스트와 장인 - 3 (6) | 2008/02/19 |
| 테스트와 장인 - 2 (0) | 2008/02/15 |
| 테스트와 장인 - 1 (2) | 2008/02/14 |
| AOP와 직교성, 그들의 도구로 RAII와 Proxy의 활용 (0) | 2008/02/12 |
| 빌드 자동화와 배치 빌드 (0) | 2007/11/30 |
작성자: yagur Rev : 1
품질 분석 그리고 개선(Quality analysis and improvement)
얼마전에 케이블 방송에서 가장 날카로운 칼에 대한 다큐멘터리를 방영하는것을 볼수 잇었다. 제목은 기억 나지 않았지만 가장 날카로운 레이저 블레이드를 파는 회사가 등장했다. 거기서 가장 인상깊게 본 장면은 자신들의 제품의 품질을 검증하기 위한 테스트가 구축되어있고 그 테스트를 통해 제품을 개선해 나가 지금의 제품을 생산해 내고 있었다는 점이다. 아래의 영상과 비슷한 실험을 통해 칼날의 품질을 테스트 하였다.
부분 품질(Partial Quality)
미션 크리티컬한 엔진 개발은 무엇으로 검증되는지 궁금할것이다.
다음 동영상은 디스커버리에서 방영한 A380에 탑제된 롤스로이스의 트렌트 900 테스트 장면이다. 이 테스트는 엔진의 팬의 구성요소중 하나인 날이 동작중 분리되는 사태에 대한 안전도 테스트이다.
왜 비행기들이 롤스로이스 엔진을 탑제하는지 알수 있는 다큐이다. 이 테스트를 위해 개발자이 200야드 떨어진 장소에서 테스트 광경을 주시한다. 이 테스트 자체가 트렌트900 개발의 중요한 마일스톤이다. 이들이 보통 이 테스트를 극비에 붙인다고 하는데 왜 공개했을까? 중요한 검증이며 신뢰도를 이보다 쉽게 줄순 없기때문이다.
비행기는 소프트웨어 시스템이고 트렌트900은 시스템을 이루는 컴포넌트이며 트렌트900 팬의 날은 클래스라고 볼수도 있다. 소프트웨어가 미션 크리티컬하지 않다고 생각한다면 테스트는 필요 없지만, 컴퓨터는 인간이 작성한 오류에 관하여 너무 정직하다. 무엇보다 미션 크리티컬한 작업이 소프트웨어 작성이다.
검증과 신뢰를 줄수 있는 방법(test)을 외면하지 말고, 적극적이 된다면 품질은 눈에 보이게 되며, 눈에 보이는 품질은 개발자에게 결과물에 대한 신뢰와 자신감을 심어줄수있다. 그 작은 예중 하나가 TDD의 녹색 막대이다.
품질 검증(Quality verify)
무엇이 완벽하게 검증을 할수는 없겠지만, 이 검증 행위는 신뢰도에 큰 도움이 되는것만은 분명하다. 만약 트렌트 900이 비와 황사에 약하다면 비행기는 롤스로이스의 제품을 탑제할수 없을것이다. 부분 품질에 소개되었던 안전성 테스트는 부분 오류와 그 파장에 대한 테스트 였다면, 아래의 두 테스트는 외부 조건에 대한 테스트이다. 특정 상황에 대한 제품의 품질을 검증하여 보장해주는 것이다.
비에 오동작할 걱정은 물을 들이 부어서 검증시켜주고, 황사에 오동작할 걱정은 모래를 들이 부어 검증해준다. 이 영상들을 보니 다음 여행때는 A380이 타고 싶어지지 않는가? 최종 사용자 입장이나 개발자 입장에서도 테스트로 검증된 유닛들은 굉장한 신뢰와 매력을 지니고 있다.
개발중인 소프트웨어 구성요소들이 외부 조건에 어떤반응을 보일지 테스트를 통해 검증하는 것은 문제가 생겼을때 혼란을 줄여줄 커다란 재산중 하나이다. 메모리가 부족할때, 디스크가 꽉찼을때, 네트워크 대역폭이 부족할때 어떤 결과를 얻기 원하는가. 지나친 테스트는 생산성을 저해할수도 있다, 하지만 검증된것을 대부분의 사람들은 좋아한다. 이름 없는 데이터 베이스와 Oracle을 사용할수 있다면 어떤 것을 사용하겠는가? 아마 열중 아홉은 오라클을 택할것이고 그 이유로 안정성과 검증된 제품이라는 말을 할것이다. 검증은 소프트웨어의 건강을 유지시켜줄것이다.
'개발 > 수필' 카테고리의 다른 글
| 테스트와 장인 - 3 (6) | 2008/02/19 |
|---|---|
| 테스트와 장인 - 2 (0) | 2008/02/15 |
| 테스트와 장인 - 1 (2) | 2008/02/14 |
| AOP와 직교성, 그들의 도구로 RAII와 Proxy의 활용 (0) | 2008/02/12 |
| 빌드 자동화와 배치 빌드 (0) | 2007/11/30 |
| 주석의 쓰임세 그리고 "중복의 해악" (0) | 2007/11/19 |
Trackback : http://yagur.impon.net/trackback/117
-
테스트에 관한 멋진글을 소개합니다. - 테스트와 장인
| 2008/03/05 08:23
우연히 알게된 블로그입니다. 테스트에 대한 멋진글이 연작으로 올라오고 있어서 소개해 드립니다. Yagur의 Juggling이라는 블로그의 테스트와 장인 입니다. 현재까지 6개가 올라와 있습니다만 앞으로 계속 쓰실거 같습니다. 제목에서 벌써 포스가 느껴지시지 않나요. ^^ 테스트와 장인1 - 품질 분석 그리고 개선(Quality analysis and improvement) 테스트와 장인2 - 주기적 테스트(Cyclic Test) 테스트와 장인3 -..
Recent Comment