썰렁한 엔지니어

연재하는 이 글들은 테스터를 위한 글이 아니라 개발자를 위한 것이며, 개발자가 어떻게 하면 테스트하면서 개발할 수 있을지에 대한 제안이다. 복사해서 쓰는 습관은 아주 초보적인 습관이지만, 가장 충동적인 습관이기도하다. 인류가 태어난 이후로 모방이라는 훌륭한 학습도구는 생활 전체에 아주 깊숙이 스며있는 것이기 때문에, 우리는 너무나 자연스럽게 가져다 쓰는 것에 익숙하다. 복사는 다른 사람 코드를 복사하는 것에서부터, 자신이 과거에 작성한 코드 그대로 복사에서 뿐아니라, 변수명이나 함수명을 바꿔서 복사 또는 기능을 추가하는 복사등, 그 변종도 아주 많다. 이 습관을 버리라고하는 이유의 핵심에는 "관리"에 있다. 혼자 연습하면서는 다른 사람의 것을 복사하는 것부터 시작하게된다. 그렇게 해야만 늘게되는 것은 자..

모듈화에 대한 개념은 초창기 분할 컴파일에서부터 시작하여, 동적 라이브러리, 나아가 플러그인, 자동화 객체와 같은 고급기능까지 비슷한 개념에서 출발하여 찬란한 꽃을 피운(?) 분야이다. 어떻게 모듈에 들어가는 함수들을 선택해야할까, 즉 어떤 함수들을 외부에서 사용하게 만들까. 그것에 대한 기준을 테스트 관점에서 바라보면 다음과 같다. 1. 외부로 노출된 함수들은 모두 테스트한다. 2. 모듈은 관련있는 기능(함수)들만을 모아 놓아야 한다. 테스트하지 않을 함수들은 모두 file scope을 가지게한다. 즉 C 언어로 말하면, static 한정자를 붙여서 외부에서 참조가능하지 않게한다. 왜 이것이 중요하냐면, 외부에서 전혀 사용하지 않는 것들이 외부로 노출될 경우 함수이름 공간에 불필요한 것이 들어가게 되고..

경험을 위주로 작성하는 것이므로 많이 보는 텍스트에서 강조하는 것을 간과할 수도있고, 없는 것도 있을 수 있는 글이 될 것 같다. 테스트 주도형 개발의 가장 기본적인 개념은 테스트 코드를 먼저 작성하고 그 코드가 돌아 갈 수 있는 함수를 만든다는 것이다. 이것만으로도 기존의 습관을 버릴 수 있는 생각의 사유가 되나 전통적인 방식(설계->구현->테스트)의 개발에 익숙한 사람이 쉽사리 옮겨가지 못하는 것은 시간에 대한 두려움이 있기 때문이다. 누구나 다 아는 사실은 테스트 코드를 먼저 작성하여 버그를 줄이는 것이 오히려 전체 시간을 줄일 수 있다는 것인데 그것은 습관적으로 진행되는 것에 의한 관성이 너무도 크기 때문에 쉽게 체득되지 않는 다. 완벽히 XP 방식의 테스트 주도형 개발을 진행하는 것이 어렵다면 ..

Test driven development 또는 Test driven programming 에 대한 내 의견은 다음과 같다. 테스트가 개발을 주도하기 위해서는 습관을 고쳐야한다. 적어도 테스트 주도형 개발의 참뜻을 알기 위해서는 개발후 모듈테스트 통합테스트, 인수테스트에 대한 과정을 수도없이 퇴짜 맞아봐야 알게 된다. 결코 테스트의 중요성은 종이위의 활자로서 얻어질 수 있는 지식이 아닌것 같다. 만일 이 글을 읽는 사람중에 그런 경험이 없다면 중요성에 대한 이해도가 덜하리라 생각된다. 모듈테스트와 통합테스트가 설계/구현다음에 일어나는 일이라 생각되기 때문에 우리는 테스트할 시간 없이 완성했다고 생각한다. 또한 혼자 개발하는 시절에는 테스트보다는 설계 구현이 더 중요시되고 그러한 사람들이 한 팀을 이루어 ..

이번에도 지난번 글과 같이 간단한 함수의 디스어셈블을 통하여 함수호출시에 일어나는 일들을 살펴보고자 한다. 참고로 이와 같은 학문(?)의 범주는 다음과 같은 위치에 있다. * C 언어 표준 스펙 * intel x86 CPU의 System V Application Binary Interface * gcc의 구현 System V ABI 를 검색어로 찾아 보면 원하는 글을 찾을 수 있을 것이다. void func6( char x1, char x2, char x3) { x1 = 1; x2 = 2; x3 = 3; } struct _p { int a1; int a2; int a3; }; void func7( struct _p p1, int p2 ) { p1.a1 = 1; p1.a2 = 2; p1.a3 = 3; p2..

C 언어는 전통적으로 다음과 같은 방식으로 실행파일이 만들어진다. (1) 편집기를 통한 소스 작성 (2) 전처리기를 통해 소스로부터 매크로 확장 및 주석 제거 (3) 컴파일러를 통해 전처리된 코드로부터 어셈블코드 생성 (4) 어셈블러를 통해 어셈블코드로부터 목적파일 생성 (5) 링커를 통해 목적파일들 (라이브러리 포함)의 결합에 의한 실행파일 생성 이 중에서 (3) 번과정을 재미로 살펴보면서 어떤일들이 일어나는지 알아보고자 한다. 테스트한 환경은 다음과 같다. * x86 CPU * gcc 3.3.2 테스트 코드는 다음과 같다. void func1() { } void func2( int x ) { x = 0; } int func3() { return 7; } void func4() { int y; y = ..

find 를 제법 잘 쓰는 사람은 다 아는 얘기일 것 같지만, 흔히들 사용하면서도 그 많은 옵션이 잘 안들어오는 사람들을 위해 정리하고자 글을 써본다. find의 철학은 그 이름에서 이미 감춰져 있다고 해도 과언이 아니다. find를 통해서 할 수 있는 것이 고작 원하는 이름의 혹은 원하는 속성을 가진 파일을 찾는 것이라 생각한다면 그것은 정말 누구나 사용할 줄 아는 방법으로서의 find 이다. find의 철학은 다음과 같다. 어디에 이런 글이 쓰여있는지는 나도 모르겠지만, 경험상 정리하자면, find 는 true/false에 의한 directory 탐색기이다. 신선한가? 우선 다들 그러하듯이 man find를 한번 수행해보고 true/false라는 말이 얼마나 나오는지 한 번 살펴보시라. 가능하면, 리..

하루에 한번씩 돌아가는 버그 어세신, 유닛 테스트는 업무중 한시간에 한 번씩 자동으로 수행하게 되어 있으며, 메일로 그 성공 여부가 전달된다. 그날의 담당자에게는 버그 어세신 푯말이 세워지고, 그날 발생하는 유닛 테스트의 버그 처리의 주 담당자가 된다. 좀더 자세히 보자 그러나.. 이렇게 하는 이유는 아무리 메일로 보고가 되어도, 메일을 자주 확인하지 않는자와, 다른 일에 치여 사는 자, 혼자 하기에 지쳐버린 자, 뭘 잘 모르는자로 구분되어서이다. 그리고 메일 한번씩 인스톨을 해보자스라. 이건 어제 선서했으므로, 지키겠지.

getpass라는 unix library function이 있다. 이 함수는 /dev/tty를 열어 echo를 끈상태로 입력을 받아 버퍼에 읽어 들인 데이터를 돌려주는 함수인데, 쉬운말로 해서, 암호를 입력받는 함수이다. 이 함수가 apr(Apache Portable Runtime) project에서 사용되며, 웹서버에 쿼리하기전 인증(Basic auth)을 하기 위해 암호열을 받는 행동을 한다. 그런데, 문제는 Apache가 관리하는 암호열이 getpass의 제약사항과는 상관없다는 것인데, getpass는 고전적으로 8자만 받아서 넘겨주는 고리타분한 행동을 한다. 리눅스의 경우 255자까지 되어 있지만, HPUX에서는 그렇지 않다는 것이다. Subversion이 apr을 이용하여 코드 저장소를 접근하는..

테스트가 드라이브하는(주도하는) 프로그래밍 쉽게 생각하기에는 테스트 코드를 반드시 작성해야한다고 생각하기 쉽지만, 이 방법은 다음과 같은 극단적인 프로그래밍 습관의 변화를 내포한다. 어떻게 사용할지 사용 형태의 샘플을 먼저 작성한다. 어떤 환경설정 파일을 사용할지 샘플 환경을 작성한다. 테스트해야할 함수와 테스트하지 않아도될 함수를 적절히 나누어 작성하게 된다. 자동화된 테스트를 위한 로그를 작성한다. 어떻게 사용할지 사용 형태의 샘플을 먼저 작성한다. 사용되는 곳에 쓰일 샘플을 먼저 작성하지 않으면, 설계의 정확한 의도를 파악하지 못한 채 작성하기 쉽다. 만약 직접 설계한 코드를 만든다고 할 지라도, 전체적인 방향이 주먹구구일 수 있다. 즉, 필요하지도 않은 인자를 함수에 전달 할 수도 있고, 필요한 ..