[실용주의 프로그래머] 테스트하기 쉬운 코드

[실용주의 프로그래머] 테스트하기 쉬운 코드

control 환경, regression testing, [실용주의 프로그래머] 테스트하기 쉬운 코드, 계약에 의한 설계 개념, 단위 테스트, 모듈 단위 테스트, 테스트 가능성, 테스트 기술, 테스트 문화, 테스트를 염두에 두고 설계하라, 통제된 환경, 회귀 테스트

소프트웨어를 만들 때 맨 처음부터 테스트 가능성을 만들어 넣고, 코드들을 서로 연결하기 전에 코드를 하나하나 철저하게 테스트해야만 한다.

모듈을 통제(control)된 환경에서 철저하게 테스트하고 나면, 더 넓은 환경에서 그 모듈이 어떻게 행동할 것인지 더 감을 잡을 수 있다.

소프트웨어 단위 테스트란 어떤 모듈에게 이것저것을 시켜보는 코드를 가리킨다.

일반적으로, 단위 테스트는 일종의 인위적인 환경을 구축한 다음, 테스트할 모듈의 루틴들을 호춣한다.

그런 다음 반환된 결과들을 이미 알고 있는 값과 비교해 보거나 똑같은 테스트를 이전에 돌렸을 때 나온 값과 비교해보아서(회귀 테스트(regression testing)) 올바른지 검사한다.

대개 프로그래머들은 임의로 아무 데이터나 만들어 코드에 넣어 보고는 테스트했다고 말하곤 한다.

계약에 의한 설계의 밑바탕에 깔린 개념들을 사용하면 훨씬 더 나은 작업을 할 수 있다.

단위 테스트를 계약을 잘 지키는지 보는 테스트로 생각하면 좋다.

어떤 단위가 자기가 맺은 계약을 존중하는지 확실하게 보여주는 테스트 케이스를 작성하고자 하면 좋다.

이런 테스트는 우리에게 두 가지 사실을 알려준다.

하나는 코드가 계약을 지키는지 여부고, 다른 하나는 코드로 표현된 계약의 의미가 우리가 생각한 것과 일치하는지 여부다.

테스트를 염두에 두고 설계하라.

애초에 에러가 나지 않게 하는 것보다 에러를 고치는데 더 좋은 방법은 없다.

사실 코드를 구현하기 전에 테스트를 먼저 만들어보면, 그 코드의 인터페이스가 고정되기 전에 미리 시험해 볼 수 있게 된다.

모듈의 단위 테스트는 소스 디렉터리 구조에서 외진 한쪽 구석에 처박혀 있어서는 안 된다.

단위 테스트는 찾기 편한 곳에 위치하고 있어야 한다.

프로젝트의 규모가 작다면, 모듈 안에 그 모듈의 단위 테스트 코드를 포함해 넣어도 된다.

프로젝트의 규모가 크다면, 각각의 테스트를 하위 디렉터리로 옮겨 놓기를 제안하다.

어떤 방식을 쓰든 간에 찾기 편한 위치가 아니면 쓰지 않게 될 것이라는 점을 기억하라.

테스트 코드를 쉽게 접근할 수 있게 해놓는 것은, 앞으로 여러분의 코드를 사용할지도 모르는 개발자들에게 매우 귀중한 두 가지 자원을 제공하는 것이다.

1. 여러분 모듈의 모든 기능을 어떻게 이용해야 하는지 보여주는 예제

2. 후일 코드 변경시 검증하기 위한 회귀 테스트를 구축할 수 있는 수단

테스트 장치(Test Harness)는 상태를 기록으로 남기거나, 예상 결과값에 비추어 출력을 분석하거나, 테스트를 선택하고 실행하는 일처럼 자주 쓰이는 작업들을 다룰 수 있어야 한다.

객체지향 언어와 환경에서는 테스트 장치의 기능을 제공하는 기반 클래스를 만들곤 한다,

개별 테스트들은 이 기반 클래스에게서 상속받아 구체적인 테스트 코드를 추가하면 된다.

표준 이름짓기 규약을 만들고 자바의 리플랙션 기능을 이용하면 테스트 목록을 동적으로 만들 수도 있다.

테스트 장치는 아래와 같은 기능이 있어야 한다.

1. 시작할 때 할일(setup)과 마칠 때 할 일(cleanup)을 지정할 수 있는 표준적인 방법

2. 개별적인 테스트들을 선택하거나, 아니면 모든 테스트를 한꺼번에 선택하게 해주는 메서드

3. 예상한 (또는 예상하지 못한) 결과에 비추어 결과를 분석할 수 있는 방법

4. 실패를 보고하는 표준화된 형태

디버깅하면서 그 자리에서 몇 가지 테스트들을 만드는 경우도 있다.

이런 임시변통 테스트는 print 문 한 줄짜리 간단한 코드일 수도 있고, 디버거나 IDE 환경과 상호작용하는 여러 줄의 코드가 될 수도 있다.

디버깅 시간이 끝나면, 이런 임시변통 코드들을 정식 테스트의 형태로 만들어 두어야 한다.

한번 잘못된 코드라면, 다시 잘못될 가능성도 높다.

여러분이 만든 테스트를 그냥 버리지 말고, 기존의 단위 테스트에 추가해 둔다.

테스트는 기술적이라기보다는 문화적인 것이다.

우리는 사용하는 언어와 상관없이 어떤 프로젝트라도 이런 테스트 문화를 스며들게 할 수 있다.

소프트웨어를 테스트하라.

그렇지 않으면 사용자가 테스트하게 될 것이다.