[이펙티브 소프트웨어 테스팅] Chapter 4. 계약 설계

이 글은 <이펙티브 소프트웨어 테스팅, 마우리시오 아니시 지음>을 참고하여 작성하였습니다.

Chapter 4. 계약 설계

계약 설계는 소프트웨어 설계 기법 중 하나로, 클래스 간의 상호작용을 계약으로 정의하는 방식입니다. 할 수 있는 계약으로는 사전 조건, 사후 조건, 그리고 불변식이 있습니다.

4.1 사전 조건과 사후 조건과 불변식

사전 조건

메소드가 제대로 동작하도록 하는 조건이 사전 조건입니다. 예를 들면, 물건 가격에 따라 세금을 계산해주는 함수에서는 입력된 물건 가격이 0보다 높아야 한다는 사전 조건을 정의할 수 있습니다. 이는 클라이언트가 지켜야하는 규칙입니다. (클라이언트에서 구현되어야하는 규칙이라는 의미는 아닙니다.)

사후 조건

산출물로 보장하는 조건이 사후 조건입니다. 예를 들면, 물건 가격에 따라 세금을 계산해주는 함수에서는 산출된 세금이 0보다 높아야 한다는 사후 조건을 정의할 수 있습니다. 이는 서버가 지켜야하는 규칙입니다.

불변식

메서드의 사전, 사후 모두의 경우에서 유지되어야 하는 조건이 불변식입니다. 예를 들면, 장바구니 클래스와 해당 클래스에 물품의 합계라는 상태 변수가 있다면, 제품의 합계는 절대 음수가 될 수 없다는 불변식을 정의할 수 있습니다.

4.2 강한 조건과 약한 조건

계약 조건은 강하게 표현될 수도 있고, 약하게 표현될 수도 있습니다.

강하게 표현한다면, 해당 조건을 만족하지 않을 때 에러를 발생시키며 프로그램을 중지해버리는 것이고, 약하게 표현한다면, 해당 조건을 만족하지 않을 때 에러 코드나 대체값을 출력시키며 프로그램이 이어 진행될 수 있도록 구현하는 것이죠.

사전 조건의 경우, 클라이언트가 좀 편하게 메서드를 사용하게 해주고 싶다면, 사전조건을 약하게 구현하기도 합니다. 실제로, 라이브러리 개발자는 사용자가 API를 편하게 사용할 수 있게 하기 위해서 약한 사전 조건을 선호하죠.

다만, 필자의 경우, 사후 조건에서 약한 조건을 사용한 적은 없다고 합니다. 사후 조건이 맞지 않는 케이스는 버그이기 때문에, 바로 탐지해야하고, 버그는 바로 고쳐져야 하기 때문이죠.

4.4 계약에 의한 설계를 해야 하는 이유

계약에 의한 설계를 해야 하는 이유는 아래와 같습니다.

첫째, 조건을 통해 제품 코드에서 버그를 일찍 발견할 수 있습니다.
둘째, 조건을 통해 개발자에게 테스트 대상을 제공합니다.
셋째, 명시적인 계약은 소비자의 삶을 편안하게 해줍니다. (클라이언트가 굳이 응답이 사후 조건에 맞는지 검증할 필요 없기에)

그리고 하지 않을 이유는 없죠. 그러니 계약에 의한 설계를 합시다!

4.5 현업에서의 팁

유효성 검사와 계약

유효성 검사는 사용자로부터 들어올 수 있는 불량 데이터가 시스템에 침투하지 않도록 미리 방지하는 것을 말합니다. 반면에, 계약은 해당 조건 위반이 일어난다면 프로그램을 중지시키는 역할을 합니다. 이렇듯, 유효성 검사와 계약은 둘의 목적이 서로 다르기 때문에, (설사 중복된다 보이더라도) 둘은 모두 이루어져야 합니다.

사전 조건, 사후 조건, 불변식에 대해 테스트를 작성해야 할까?

필자는 유효성 검사에 대해서는 테스트를 작성하는데, 단언문에 대해서는 테스트를 거의 작성하지 않는다고 합니다.

단언과 예외

비즈니스 클래스와 클래스 간의 계약을 모델링하고 있고, 사전 조건이나 사후 조건을 위반하리라고 생각하지 않기 때문에 그 때에만 assert 문 사용을 선호한다. 하지만, 그 외에는 예외를 사용하자.