이펙티브 소프트웨어 테스팅 - 계약 설계 : 사전/사후조건, 불변식 (1)

stayhere 2023. 4. 19. 23:11

계약에 의한 설계는 오브젝트 책에서도 소개된 내용인데

이 책에서는 해당 내용에 영감을 받아 테스트의 관점에서 이 내용을 다루고있다.

1. 유효하지 않은 입력으로는 절대 해당 클래스를 호출할수 없게 만듬.

=> 이 방법은 해당 클래스를 호출하는 클래스에 복잡성이 추가된다.

2. 프로그램을 방어적으로 작성하는 방법

=> 잘못된 입력이 발생하면 시스템이 중단되고 에러를 전달한다.

=> 이 경우 시스템에 있는 모든 클래스의 복잡성이 약간 증가되는데, 잘못된 입력을 어떻게 다루어야 하는지 알아야 하기 때문이다.

3. 각 클래스에 대한 명확한 계약을 정의한다

=> 저자는 이 방법을 가장 선호하는데, 이것은 책의 목표이기도 하다

계약이란 클래스가 사전조건으로 무엇을 요구하는지, 클래스는 사후조건으로 무엇을 제공하는지, 불변식은 클래스에 대해 항상 무엇을 유지하도록 하는지를 명확하게 설립한다.

사전조건 - 메서드가 제대로 동작하도록 한다.

사후조건 - 메서드가 산출물을 보장한다.

메서드에 대해 사전조건과 사후조건을 수립했으면, 소스코드에 이를 추가하게 된다.

가장 간단한 방법은 if문을 추가하는것이다.

사전조건 - 유효하지 않은 값이 통과되지 않도록 한다

사후조건 - 무언가 잘못되었다면 예외를 던져서 사후조건을 만족하지 않는다고 경고한다.

문서에 이를 기술하는것 역시 중요하다.

java의 assert 키워드 - 만족하지 않으면 AssertionError을 던진다.

사전조건을 검사하는것과 assert를 사용할지 말아야 할지, 오류를 던질지등 다양한 선택사항이 있다.(나중에 자세히 다룬다)

사전/사후 조건을 정의할때 중요한점은 조건의 강도를 어느정도로 할지이다.

사전조건을 위반시 프로그램을 중지시킨다면 매우 강한 사전조건이다.

약한 사전조건은 다른 클래스가 메서드를 쉽게 호출할수 있도록하고, 전달받은 값에 상관없이 어떤 값을 반환하게 된다.

강한조건을 쓸지 약한 조건을 쓸지 정답은 정해져 있지 않고 케이스 바이 케이스다.

=>강한조건은 코드에서 발생할수 있는 실수의 범위를 줄여주는 경향이 있다.

=>하지만 이 경우는 조건을 단언문으로 바꾸게 되고, 코드는 더 복잡해진다.

불변식은 어떤 객체나 데이터 구조의 생명주기 전체에 해당하는 조건을 가진다.

장바구니 기능의 remove 구현의 예를들어보자

사전조건: 입력값인 제품이 널이면 안된다, 또한 장바구니에 들어있어야 한다.

사후조건: 제품이 더이상 장바구니에 있으면 안된다.

사전조건, 사후조건을 모두 작성하고 나면, 클래스 불변식을 모델링할 때이다.

예를들어 장바구니에서 더하고 빼는 행위와 관계없이, 장바구니에 있는 제품의 합계는 절대 음수가 될 수 없다.

불변식은 메서드 실행중에 유지되지 않을수도 있다. 하지만 메서드 호출이 끝났을때, 결국에는 불변식이 유지되도록 보장할 필요가 있다.