테스트, 언어선택

07 | 테스트
나는 에러를 수정하는 모뎀이 있으므로 따로 프로그램을 테스트할 필요가 없다.

— Om I. 바우드Om I. Baud

프로그램에 버그를 남겨둠으로써 유지보수 프로그래머에게도 재미있는 일거리를 제공해야 한다. 잘 만든 버그라면 어디서 어떻게 발생했는지에 관한 단서를 남기지 않는다. 버그를 남겨두는 가장 게으른 방법으로는 우리 코드를 절대 테스트하지 않 는 방법도 있다.

절대 테스트하지 마라

에러나, 기기 크래쉬, OS 결함을 처리하는 코드는 절대 테스트하지 않는다. OS가 반환하는 코드도 검사하지 않는다. OS가 반환하는 코드는 실행에 아무 도움이 되지 않으며 우리 테스트 시간만 오래 걸리게 한다. 게다가 우리 코드가 디스크 에러, 파 일 읽기 에러, OS 크래쉬와 같은 모든 경우를 적절하게 처리하는지 어떻게 일일이 테스트할 수 있겠는가? 도대체 왜 컴퓨터 시스템을 신뢰할 수 없는 것처럼 생각하고 교수대 같은 것이 제대로 동작하지 않는지 테스트해야 하는지 이해할 수가 없다. 최 신 하드웨어에서는 에러가 발생하지 않는다. 그러나 아직도 누군가는 테스트 전용 코드를 구현하는가? 정말 지치는 일이 아닐 수 없다. 사용자가 우리 프로그램의 문 제에 대해 불평한다면 사용자가 잘 알 수 없는 OS나 하드웨어 탓으로 떠넘기자.

세상이 무너져도 성능 테스트를 하지 않는다

프로그램이 좀 느리다고? 고객에게 더 빠른 컴퓨터를 사라고 말하자. 성능 테스트 를 수행했다면, 문제가 일어나는 지점을 찾았을 것이다. 아마 문제를 해결하려면 알고리즘을 변경해야 할 것이고 제품 전체를 완전히 다시 설계해야 하는 경우도 생 길 수 있다. 이런 일을 누가 하고 싶어 하겠는가? 게다가 고객사에 성능 문제가 불쑥 나타난다는 것은 이국적인 곳으로 공짜 여행을 할 수 있는 기회일 수 있다. 정말로

우리가 해야 할 일은 여권을 항상 가까이에 소지하면서 상황을 예의주시하는 것이다.

절대 테스트 케이스를 만들지 않는다

코드 커버리지나 패스 커버리지 테스트를 절대 수행하지 말자. 자동화 테스트는 겁쟁이나 하는 짓이다. 우리 루틴의 90%에 해당하는 기능을 찾고, 전체 테스트의 90%를 이러한 기능 확인에 사용한다. 결과적으로 이 기법으로는 우리 코드의 약 60% 정도만 검증을 한 셈이 되고 40% 정도의 노력을 절약할 수 있다. 절약한 시 간으로 프로젝트의 백엔드 계획을 수립할 수 있다. 멋진 “마케팅 기능”이 동작하지 않는다는 사실을 알아차리기 전에 회사를 조용히 떠날 수 있다면 정말 짜릿한 경험 이 될 것이다. 크고 유명한 소프트웨어 회사는 이런 방식으로 코드를 테스트한다. 따라서 위 방법을 사용할 것을 추천한다. 어떤 이유에서인지 모르겠지만 혹시 위 계획을 실천하지 못하고 아직 회사에 남아있어야 한다면 계속해서 이 문서를 읽기 바란다.

겁쟁이 전용 테스트

용감한 코더는 이 단계를 건너뛴다. 상사를 무서워하고, 직장을 잃을까 두려워하 고, 고객의 불평 메일을 받거나 고소당하는 일을 걱정하는 프로그래머가 너무 많 다. 이러한 두려움 때문에 행동에 제약을 받고, 생산성이 떨어진다는 것은 누구나 아는 사실이다. 연구에 따르면 테스트 단계를 없애는 것이 관리자로 하여금 출시일 을 미리 결정할 수 있게 하는 등 계획 단계부터 많은 도움이 된다. 두려움이 없어진 다면 혁신과 실험정신이 창궐할 수 있다. 프로그래머는 코드를 생산하는 데 주력할 수 있고, 헬프 데스크와 기존 유지보수 그룹이 협력해서 디버깅을 담당할 수 있다. 우리의 코딩 능력을 온전히 믿는다면 테스트 따위는 더 이상 불필요하다. 논리적으 로 생각해보면 테스트라는 것은 감정적인 자신감 결여 문제일 뿐, 기술적으로 문제 를 해결하지도 않는다는 점을 바보라도 눈치챌 수 있다. 자신감 결여 문제는 테스 트 과정을 완전 제거하고 프로그래머를 자신감 회복 과정에 보냄으로 해결할 수 있 다. 테스트를 하려면 프로그램을 변경할 때마다 테스트를 해야 한다. 프로그래머를 자신감 향상 프로그램에 보내는 것과 테스트를 하는 것, 어떤 것이 바람직한 일인 가? 비용 절감 효과는 상상을 초월할 것이다.

디버그 모드에서만 동작하는 코드

TESTING을 1로 정의했다면,

#define TESTING 1

아래와 같이 TESTING이 1인 경우에만 수행되는 별도의 코드 섹션을 가질 수 있다.

#if TESTING==1 #endif

별도의 코드 섹션에 다음과 같은 꼭 필요한 코드를 넣고 빼는 것은 우리의 자유다.

x = rt_val;

누군가 TESTING을 0으로 재설정하면 프로그램은 동작하지 않는다. 조금만 창의력 을 발휘하면 이 기법으로 로직을 망가뜨리고 컴파일러 기능 장애를 초래할 수 있다.

08 | 언어선택
철학이란 언어를 사용해 우리의 지성이라는 마력에 대항하는 싸움이다.

_루트비히 비트겐슈타인Ludwig Wittgenstein

컴퓨터 언어는 바보 같은 동작을 방지하는 방향으로 점차 변화하고 있다. 최첨단 언어에 의존하는 것은 남자답지 못한 행동이다. 우리가 사용할 수 있는 가장 오래 된 언어 사용을 고집하자. 가능하다면 8진법 기계어(필자는 Hans와 Frans처럼 계 집애 같은 남자가 아니다. 나는 남성미 넘치는 사람으로 IBM의 레코드 장비(펀치 카드)의 플러그보드에 직접 케이블을 꽂아가며 코딩을 하거나 종이 테이프에 펀치 를 이용해 구멍을 뚫어 코딩을 했던 사람이다)를, 안 된다면 어셈블러, 안 되면 포 트란이나 코볼이라도, 안 되면 C, 안되면 베이직, 안되면 C++로 시도하자.

포트란(FORTRAN)

포트란으로 코드를 작성하라. 상사가 그 이유를 묻는다면 포트란에는 유용한 라이 브러리가 많아서 시간을 절약할 수 있다고 대답하자. 포트란으로 작성한 코드를 유 지보수할 수 있는 확률은 0이다. 따라서 유지보수할 수 없는 코드 가이드라인을 지 키기가 아주 쉬워진다.

Ada를 피하라

여기서 설명한 기법 중 약 20%는 Ada에 사용할 수 없다. Ada 사용은 적극 피해야 한다. 관리자가 우리를 압박하면 다른 사람 모두 Ada를 사용할 수 없다고 주장하 고, lint나 plummer 같은 우리의 커다란 도구 스위트와 맞지 않는다는 점을 부각 하자.

ASM 사용

모든 공통 유틸리티 함수를 asm으로 변환하자.