"이펙티브 소프트웨어 테스팅" 정리

 

 

1. 효율적이고 체계적인 소프트웨어 테스트

• 버그 찾기 → 소프트웨어 테스트의 전부
• 버그는 경계값을 좋아한다.
  • 최소 필요한 값이 10일 경우, 10의 경곗값(9~11)
• 제품 코드의 행동을 빠르게 기술하는 간단한 테스트를 보유하는 것은 테스트 스위트에 약간의 중복이 있더라도 항상 득이 된다.
• 소프트웨어를 올바로 테스트하려면 그렇게 안 하는 것보다 일이 더 많아지만, 그럼에도 왜 가치 있는 일인가?
  • 상용 버전에서 발생하는 버그의 비용은 예방하는 비용보다 훨씬 더 크다
  • 버그를 찾고, 해결, 개선하는 과정이 오히려 시간을 많이 소모한다.
  • 연습이 관건 → 테스트 케이스 작성에 익숙해지면 더 빨리 작성할 수 있다.
• 효율적 → 올바른 테스트를 작성하는 데 집중
• 체계적 → 어떤 코드 조각에 대해 어느 개발자라도 같은 테스트 스위트를 만들어낸다는 것
• 테스트 업무의 어려운 점은 JUnit 코드를 작성하는 게 아닌 테스트 케이스가 버그를 드러내도록 제대로 설계하는 일
• “검증은 시스템이 제대로 되어 있는가에 관한 것, 유효성 검사는 올바른 시스템을 가지는 방법에 관한 것”
• 클래스 설계 방식은(아키텍쳐) 단위 테스트를 얼마나 쉽게 작성할 수 있는가에 큰 영향을 미친다.

💡 단위 테스트는 시스템에서 작업 단위를 호출하는 자동화된 코드 조각, 작업 단위는 한 메서드, 한 클래스 또는 함께 동작하는 여러 클래스에 이를 수 있고, 검증 가능한 단 하나의 논리적 목표를 달성한다. (로이 오쉐로브, 2009)

 

요약

• 체계적이고 효율적인 소프트웨어 테스트를 통해 코드 구석구석을 실행하고 완성도 있는 케이스를 설계하자.
• 완벽한 테스트는 불가능, 테스트가 얼마나 필요할지에 대해 절충안을 마련하자.

 

2. 명세 기반 테스트

💡 학습 내용
    - 명세 기반 테스트 기법을 적용하여 테스트 케이스 작성하는 방법
    - 프로그램 경계에 대한 테스트 케이스를 식별하고 작성하는 방법

• 경계 테스트: 프로그래머가 경계 근처에서 발생하는 버그를 만들 확률은 다른 입력값에 비해 더 크다.

2.2 간략히 살펴보는 명세 기반 테스트

1. 요구사항 이해
   • 프로그램이 무엇을 수행해야 하는지, 말아야 하는지, 특정 케이스, 변수 타입, 입력 도메인 등
2. 프로그램 탐색
   • 프로그램 가지고 놀기
3. 구획 식별
   • 입력 변수 타입, 범위, 변수 간 상호작용, 의존성, 출력값 등
4. 경계 분석
5. 테스트 케이스 고안
6. 테스트 자동화
7. 강화

요약

• 요구사항은 테스트를 만드는 데 가장 중요한 참고 자료다.
• 명세 테스트를 위한 7단계 접근법을 제안한다.
• 버그는 경계를 좋아하지만, 경계 식별하는 일은 가장 어려울 수 있다.
• 단순한 프로그램도 테스트 케이스의 수가 매우 늘어날 수 있으니 잘 판단하고 결정하자.

 

3. 구조적 테스트와 코드 커버리지

💡 학습 내용
    - 코드 구조를 기반으로 테스트 케이스를 생성하는 방법
    - 구조적 테스트와 명세 기반 테스트의 결합
    - 코드 커버리지 활용법 & 일부 개발자는 싫어하는 이유

3.2 구조적 테스트 간략히 살펴보기

• 구조적 테스트: 소스 코드의 구조를 사용하여 테스트를 도출하는 것
• 구조적 테스트 기법을 이해한다는 것은 커버리지 기준을 이해한다는 뜻

1. 명세 기반 테스트를 수행
2. 구현 사항을 읽고, 주요 결정 사항 이해
3. 작성한 테스트 케이스를 코드 커버리지 도구로 수행하자.
4. 테스트가 수행되지 않은 코드에 대해 …  
   - 왜 수행되지 않았는지, 테스트할 가치가 있는지, 필요하다면 테스트 케이스를 구현하자.

• 가장 중요한 점은, 구조적 테스트는 이전의 명세 기반 테스트로 고안한 테스트 스위트를 보강
• 100% 커버리지가 시스템을 제대로 테스트했다는 것을 의미하지는 않지만, 커버리지가 낮다는 것은 시스템이 제대로 테스트되지 않았다는 것을 의미한다.

3.10.6 무엇을 (테스트) 수행하지 말아야 할까?

• catch 블록, equals&hashCode, getter/setter, 생성자 등
• 모든 코드는 다른 방식으로 증명될 때까지 수행되어야 한다.

요약

• 구조적 테스트의 전반적 개념은 코드의 어떤 부분이 아직 수행되지 않았는지를 분석 및 수행할지 살펴보는 것

4. 계약 설계

 💡 학습 내용
    - 사전 조건, 사후 조건, 불변식을 설계하는 방법
    - 계약과 유효성 검사의 차이점에 대한 이해

• 클래스에 대해 명확한 계약을 정의하는 것?
  • 클래스가 사전 조건으로 무엇을 요구하는지, 사후 조건으로 무엇을 제공하는지, 불변식은 클래스에 대해 항상 무엇을 유지하도록 하는지를 명확하게 설립
  • 사전 조건: 메서드가 받아들인 입력값이 요구사항을 준수하도록 보장
  • 사후 조건: 메서드가 다른 메서드에 약속한 것을 반환하도록 보장
• 문서에 사전, 사후 조건을 명확히 기술하는 일 역시 중요하고 매우 권장된다.

/**
 * 세금 계산 ...
 * @param value 세금 계산을 위한 값, 값은 양수여야 한다.
 * @return 계산한 세금, 세금은 항상 양수여야 한다.
*/

4.5.4 예외 vs 부드러운 반환값

• 클라이언트의 삶을 단순하게 만드는 방법은 예외를 던지지 말고 메서드 반환값을 ‘부드럽게’ 만드는 것
  • 일어나서는 안 되는 동작이 발생할 때 클라이언트가 그것을 어떻게 다루어야 할지 모른다면 예외
  • 클라이언트가 계속 작업할 수 있도록 한다면 부드러운 값 반환 (substring)

요약

• 계약을 설계하는 일은 클래스와 메서드의 사전 조건, 사후 조건, 불변식을 명시적으로 정의하는 것
• 유효성 검사와 계약 검사는 서로 다른 목표를 가지며, 둘 다 수행해야 한다.
• 계약을 변경할 때마다 변경으로 인한 영향을 파악해야 한다.

 

5. 속성 기반 테스트

💡 학습 내용
    - 속성 기반 테스트를 작성하는 방법
    - 속성 기반 테스트 또는 예시 기반 테스트를 언제 작성해야 하는지

• 테스트를 위해 메서드를 추가하는 게 좋지 않은 생각일까? → 트레이드 오프
• 저자는 종종 테스트를 쉽게 해주는 것은 무엇이든 좋아한다.

 

6. 테스트 더블과 모의 객체

💡 학습 내용
    - 스텁, 페이크, 모의 객체를 사용해서 테스트를 단순화하는 방법
    - 모의 객체가 무엇인지, 모의 객체를 언제 사용해야 하는지, 언제 사용하지 말아야 하는지에 대한 이해
    - 모의할 수 없는 객체를 모의하는 방법

• 다른 클래스에 의존하는 클래스를 테스트할 때 의존성을 사용하지 않는 방법을 알아내야 하는데, 이때 테스트 더블이 도움이 된다.
• A 클래스가 데이터베이스 값을 가져오기 위해 IssuedInvoices에 의존하는 값을 하드 코딩된 목록을 반환하는 IssuedInvoices를 구현할 수 있다.
• 즉, A 주변의 환경을 제어함으로써 복잡한 종속성을 처리하지 않고 A의 동작 방식을 나타낼 수 있다.
• 다른 객체의 동작을 시뮬레이션하는 객체를 사용하는 장점  
  • 더 큰 제어권을 가진다. (가짜 객체에게 무엇을 해야 할지 쉽게 알려줄 수 있다.)
  • 시뮬레이션은 빠르다.
  • 클래스 간 상호작용을 반영할 수 있다. (테스트 용이성)

6.1 더미, 페이크, 스텁, 모의 객체, 스파이

6.1.1 더미 객체

• 더미는 테스트 대상 클래스에 전달되지만 절대 사용되지 않는 객체
• 비즈니스 애플리케이션에 전달해야 할 인수가 여러 개 있지만, 테스트는 이들 중 몇 개만 수행할 때

/* Customer가 어떤 Adress를 가지든지 상관하지 않을 수 있다. 
 * 이럴 경우 테스트는 더미 Adress 객체를 설정해서 Customer 클래스에 넘길 수 있다.
**/
public class Customer {
	private Long id;
	private Address adress;
	private Email email;
}

6.1.2 페이크 객체

• 페이크 객체는 시뮬레이션하려는 클래스같이 실제로 동작하는 구현체를 가진다.
• 하지만 똑같이 동작하는 것이 아닌 훨씬 단순한 방법으로 동작한다.

6.1.3 스텁

• 스텁은 테스트 과정에서 수행된 호출에 대해 하드 코딩된 응답을 제공한다.
• 페이크 객체와는 달리 스텁은 실제 동작하는 구현체가 없다.

6.1.4 모의 객체

• 모의 객체는 메서드의 응답을 설정할 수 있다는 점에서 스텁 같은 역할을 한다.
• 하지만 모의 객체는 모든 상호작용을 저장해서 나중에 단언문에 활용할 수 있도록 해준다.
• 모킹 프레임워크를 사용하여 ‘메서드는 어떤 특정 매개변수로 호출되지 않는다’ 또는 메서드는 매개변수 A로 두 번 호출되고 매개변수 B로 한 번 호출된다와 같은 모든 종류의 상호작용을 단언할 수 있다.

6.1.5 스파이

• 스파이는 의존성을 감시한다, 실제 객체를 감싸서 그 행동을 관찰한다.
• 모의 객체를 사용하는 것보다 실제 구현하는 게 훨씬 더 쉽고, 테스트 대상 메서드가 의존 대상과 어떻게 상호작용하는지 단언하고자 하는 경우에 사용된다.

6.2 모의 객체 프레임워크 (모키토, Mockito)

• 모키토는 매우 간단하기 때문에 다음 세 가지 메서드만 알아도 충분하다.
  • mock(<class>): 주어진 클래스로 모의 객체 또는 스텁 생성
  • when(<mock>.<method>).thenReturn(<value>): 메서드의 동작을 정의하는 연속된 메서드 호출
  • verify(<mock>).<method>: 모의 객체와의 상호작용이 예상된 방식대로 일어났는지 검증

6.3 현업에서의 모의 객체

• 언제 모의 객체를 사용해야 하고, 언제 사용하지 말아야 하는가?
• 누군가는 사용해야 하고, 누군가는 모의를 하면 안 된다고 믿는 사람들도 있다.

6.3.1 모의 객체의 단점

• 모의 객체를 사용하는 것은 테스트 스위트가 코드가 아닌 모의 객체를 테스트하도록 만든다고 믿는다.
• 모의 객체를 사용하면 자연스럽게 테스트를 덜 현실적으로 만든다.
  • A → B 의존, B의 sum() 메서드는 항상 양의 숫자를 반환하고, 이를 모의 객체로 작성 하고,
    얼마 후 B의 sum() 메서드는 음의 숫자를 반환하도록 비즈니스 변경되었다.
    B의 단위 테스트에 대해서만 수정하고, A가 신규 사후 조건을 잘 처리하는지 검사하는 일을 까먹기 쉬운데, 더 나쁜 점은 A의 테스트는 여전히 통과한다..
  • 모의 객체가 클래스의 실제 계약을 표현하지 않을 수 있다는 점에서 모의 객체에 대한 제어권을 잃기 쉽다.
  • 따라서 모의 객체가 대규모로 잘 동작하게 하려면 계약을 신경 써서 설계해야 한다.
• 모의 객체를 사용한 테스트는 자연스럽게 모의 객체를 사용하지 않는 테스트 코드와 결합하게 된다.
  • 테스트 메서드는 제품 코드에 대해 너무 많이 알고 있다.
  • 이는, 테스트를 변경하기 힘들 수 있는데 실제 클래스의 동작을 변경하면 테스트 역시 변경 가능성 존재함
• 따라서, 모의 객체는 테스트를 단순하게 해주지만 테스트와 제품 코드의 결합도를 증가시킨다.

6.3.2 모의해야 하는 대상과 하지 말아야 하는 대상

실용적으로 의존성이 다음과 같은 종류일 때 모의 객체나 스텁을 사용한다.

1. 의존성이 너무 느린 경우
2. 의존성이 외부 인프라와 통신하는 경우
3. 의존성을 시뮬레이션하기 힘든 경우

반면 다음과 같은 경우는 모의 객체나 스텁을 꺼리게 된다.

1. 엔티티(Entity)
2. 네이티브 라이브러리와 유틸리티 메서드
3. 충분히 단순한 의존성

6.3.5 모의에 관한 외부 의견 (구글 엔지니어는 이렇게 일한다)

• 테스트 더블을 사용하려면 시스템이 테스트 가능성을 가지도록 설계해야 한다.
• 실제 구현에 충실하게 테스트 더블을 구축하는 일은 어려우나 가능한 한 그렇게 해야 한다.
• 고립성보다 현실성이 낫다. (가능하다면) 페이크, 스텁, 모의 객체보다 실제 구현을 선택하자.
• 모의를 너무 많이 사용하면 위험해질 수 있다.
  • 테스트 불분명(이해하기 어려움), 깨지기 쉽고, 덜 효과적(결함 탐지 능력이 감소) 때문
• 너무 구체화된 상호작용 테스트는 피하자. 인수 및 기능 테스트에 초점을 두자

요약

• 테스트 더블은 느리거나 복잡하거나 외부 구성요소에 의존하고 있어 제어하거나 동작을 관찰하기 힘든 클래스를 테스트하는 데 도움이 된다.
• 모의 객체는 테스트에 도움이 되나 단점도 있다. (실제 구현과 다를 수 있음) → 테스트는 성공, 시스템은 실패
• 모의 객체를 사용하는 테스트는 그렇지 않은 테스트에 비해 제품 코드와 더 많이 결합된다.

7. 테스트 가능성을 위한 설계

💡 학습 내용
    - 아키텍처, 설계, 구현 수준에서 테스트하기 쉬운 코드를 설계하는 방법
    - 육각형 아키텍처, 의존성 주입, 관찰 가능성 및 제어 가능성에 대한 이해
    - 테스트 가능성의 함정을 회피하는 방법

• 항상 테스트 가능성을 생각하고, 처음부터 설계해야 한다.
• 테스트 가능성을 위한 설계가 노력을 들일 만한 가치가 있을 것이라고 설득하는 것이 이 장의 목표

7.1 도메인 코드에서 인프라 코드를 분리하기

• 육각형 아키텍처(헥사고날)을 기반으로 인프라를 비즈니스 코드로부터 분리하는 것의 예시를 설명하고 있음
• 도메인 클래스에서 인프라의 구현체(어댑터)를 숨기고, 추상화(포트)에 의존함으로써 포트를 스텁, 모의 객체로 만들어서 도메인 로직의 동작을 쉽게 수행할 수 있음

쇼핑 카트 예제 헥사고날 아키텍처 패턴

7.2 의존성 주입과 제어 가능성

• 전통적인 방식의 코드는 의존성을 직접 생성하는데, 이는 클래스 내부를 제어하지 못하도록 하고, 모의 객체로 단위 테스트를 작성하지 못하도록 만든다.
• 의존성을 주입할 수 있도록 하면 여러 면에서 코드를 개선할 수 있다.
  • 테스트 도중 의존성을 모의 객체, 스텁으로 생성이 가능하고 테스트 단계에서 생산성을 증대한다.
  • 의존성을 더 명확하게 해준다.
  • 관심사 분리에 좋다.
  • 클래스가 더 확장성을 가지게 된다. (다형성 등)
• 의존성 역전 원칙!!
  • (비즈니스 클래스 같은) 고수준 모듈은 저수준 모듈에 의존해서는 안 되고, 이 둘 모두 (인터페이스 같은) 추상화에 의존해야 한다.
  • 추상화는 세부사항에 의존하면 안 된다. 세부사항(구현체)은 추상화에 의존해야 한다.
  • << 도메인 - 포트 ← 어댑터 >> 생각

7.4 의존성 전달 방법: 클래스 생성자와 메서드 매개변수

// 생성자를 통해 의존성 전달
public class ChristmasDiscount {
  private final Clock clock;

  public ChristmasDiscount(Clock clock) {
    this.clock = clock;
}

  public double applyDiscount(Double rawAmount) {
    LocalDate today = clock.now();
    ...
    }
}

// 매개변수에 의존성 전달
public class ChristmasDiscount {

  public double applyDiscount(Double rawAmount, LocalDate today) {
    	...
    }
}

• 의존성을 사용하지 않고 메서드 매개변수를 통해 직접 원하는 값을 전달하는 방법의 장단점?
  • (+) 구현과 테스트 측면에서 가장 간단한 해결책일 수 있다.
  • (-) 이 클래스를 호출하는 모든 곳에서 인수를 제공해야 한다
• 클래스, 테스트의 복잡도 증가 + 클라이언트 단순 호출
• 클래스, 테스트의 복잡도 감소 + 클라이언트 복잡도 약간 증가

7.5 현업에서의 테스트 가능성 설계

• private 메서드는 오로지 public 메서드를 통해서만 테스트해야 한다.
• 위가 아니라면 private 메서드의 응집도가 떨어지고 복잡하기 때문인데, 테스트가 우리에게 무언가를 알려주는 좋은 예시 (메서드 분리 등)

요약

• 테스트 불가능한 코드는 우리 삶을 힘들게 한다. 테스트하기 쉬운 코드를 작성하도록 하자.
• 도메인 코드에서 인프라를 분리하자.
• 신뢰할 수 없는 방법으로 코드를 변경해서는 안 되지만, 실용적으로는 테스트에 도움이 되도록 제품 코드를 변경하는 것에 전적으로 찬성한다.

8. 테스트 주도 개발 (TDD)

💡 학습 내용
    - 테스트 주도 개발에 대한 이해
    - TDD로 생산성을 높이는 방법
    - TDD를 사용하면 안 되는 경우

8.3 현업에서의 TDD

• 필자는 TDD가 주는 리듬에 감사한다.
  • 다음으로 개발할 가장 간단한 기능을 찾고, 테스트를 작성하고, 필요한 만큼 구현하며, 작업 내용을 고찰하는 일로 인해 개발 속도에 따라 조절 가능

8.3.2 항상 TDD를 사용해야 할까? (X)

• 설계, 아키텍처, 특정 요구사항에 대한 구현 방법이 명확하지 않을 때 TDD를 사용
• 복잡한 문제를 다루거나 그 문제에 전문성이 부족할 때 TDD를 사용
• 개발 과정에서 배울만한 게 없으면 TDD를 사용하지 않는다. (바로 코딩)
• TDD는 설계 관점에서뿐만 아니라 구현 관점에서 작성중인 코드를 배울 수 있도록 해준다.

9. 대규모 테스트 작성

💡 학습 내용
    - 대규모 테스트를 언제 작성해야 하는지
    - 신뢰성 있는 통합 테스트와 시스템 테스트를 고안하는 방법

9.1 대규모 테스트 사용 시기

• 각 개별 클래스에 대한 테스트는 수행했으나, 전체 동작이 여러 클래스로 구성되어 있어 함께 구동될 때 어떠한 일이 일어나는지 확인하고 싶을 경우
• 테스트하려는 클래스가 거대한 플러그 앤 플레이 아키텍처의 구성요소일 때

9.2 데이터베이스와 SQL 테스트

9.2.1 SQL 쿼리에서 테스트해야 하는 것

• 첫 번째 → 데이터베이스에 데이터를 미리 설정한 후 테스트 (SELECT 테스트)
  • 테스트는 실패할 수 있음

9.2.3 SQL 테스트를 위한 인프라 설정

• 통합 테스트를 위한 부모 클래스 생성하기 (SQLIntegrationTestBase)
  • 연결 생성 + 정리 + Close
  • 이러한 장점은, 추후 변화가 일어날 때 모두 한곳에서 일어나게 된다는 것
  • 재활용하는 코드

9.2.4 모범 사례

• 테스트 데이터 생성기를 사용하자 (10장)
  • 테스트 객체를 생성해주는 도우미 클래스
• 단언 API를 잘 만들어서 재활용하자
• 필요한 데이터를 최소화하자
• 스키마의 변화를 고려하자

9.4 대규모 테스트에 대한 마지막 논의

9.4.1 테스트를 어느 수준으로 해야 할까?

• 모든 것을 단위 수준에서 수행하고, 대규모 테스트에서는 가장 중요한 행위를 수행하자.

9.4.2 비용/이득 분석을 수행하자

• 이 테스트를 작성하는 데 비용이 얼마나 들까?
• 실행하는 데 드는 비용은?
• 이 테스트로 얻을 수 있는 이득은 무엇인가? 어떤 버그를 잡을 수 있을까?

9.4.4 적합한 코드 인프라가 핵심이다

• 통합 테스트, 시스템 테스트는 둘 다 배후에 적절한 인프라가 필요하다.
• 테스트 인프라에 투자하는 것이 핵심이다. (환경 설정, 초기화, 검색, 단언 등의 작업)

요약

• 테스트 작성 → 비용 < 이득
• 단위 테스트가 항상 단순하고, 비용이 저렴하다 - 단위 테스트에 대한 확신 → 전체 시스템 확신

 

10. 테스트 코드 품질

💡 학습 내용
    - 우수하고 유지 보수하기 쉬운 테스트 코드를 작성하는 원칙과 모범 사례
    - 테스트 코드의 이해와 발전을 저해하는 테스트 냄새를 없애는 방법

10.1 테스트 코드의 유지 보수성을 위한 원칙

10.1.1 테스트는 빨라야 한다.

• 테스트 코드를 통해 얻는 피드백은 빠를수록 좋다.
• 테스트가 느리다면 다음 상황을 고려해 보자.
  • 모의 객체나 스텁을 이용해서 테스트의 일부 느린 구성요소를 대체한다.
  • 제품 코드를 재설계해서 느린 코드를 빠른 코드와 분리하여 테스트할 수 있도록 한다.
  • 느린 테스트를 자주 실행하지 않는 다른 테스트 스위트로 옮긴다. → 느린 테스트는 따로 실행

10.1.2 테스트는 응집력 있고 독립적이며 격리되어야 한다

• 하나의 테스트 메서드가 하나의 기능이나 시스템의 행위를 테스트하는 것이 이상적이다.
• 테스트가 자신이 만든 지저분한 사항을 정리하도록 하자.
  • 디스크에 생성된 파일 삭제 및 데이터베이스에 입력한 값 삭제 등 초기화 상태

10.1.4 테스트는 반복 가능해야 하며 불안정하지 않아야 한다

• 반복 가능한 테스트는 실행 횟수에 상관없이 결과가 동일하다.
• 테스트는 여러 이유로 불안정해진다.
  • 외부 자원이나 공유 자원에 의존하는 경우 (ex. 파일 경로, 데이터베이스)
  • 부정확한 타임아웃
  • 다른 테스트 메서드와 예상치 못한 상호작용이 일어난 경우
• Luo 외 연구진(2014)이 밝혀낸 불안정한 테스트의 원인
  • 비동기식 대기, 동시성, 테스트 순서 의존성
  • 대부분의 불안정한 테스트는 작성할 때부터 불안정하다.
  • 불안정한 테스트가 플랫폼 특성으로 인해 발생하는 일은 드물다 (다른 운영체제 등)
  • 불안정성은 종종 외부 자원에 대한 의존성으로 인해 발생하며, 각 테스트가 끝나고 실행되는 사이에 공유되는 상태를 정리하여 해결할 수 있다.

10.1.6 테스트는 행위가 변경될 경우 깨져야 한다

• 테스트를 통해 예상된 행위가 깨졌음을 알 수 있다.

10.1.8 테스트는 작성하기 쉬워야 한다

• 통합 및 시스템 테스트에서는 외부 인프라를 설정하고 정리하는 테스트도 필요하다.
• 항상 테스트를 작성하기 쉽게 하고, 개발자에게 그렇게 할 수 있는 모든 도구를 제공하자.
• 우수한 테스트 인프라를 구축하는 데 시간을 투자하는 것은 필수이며 장기적으로 성과를 보게 된다.

10.1.9 테스트는 읽기 쉬워야 한다

• 코드 가독성, 제품 코드에 사용하는 방식 관련해서는 테스트 코드에도 적용된다.
• 테스트를 읽기 쉽게 하기 위한 두 가지 원칙
  • 모든 정보(입력, 단언문)가 충분히 명확한지 확인하고,
  • 복잡한 데이터 구조를 작성할 때마다 테스트 데이터 작성기를 사용한다.

10.2 테스트 냄새

10.2.4 너무 범용적인 픽스처

• 테스트의 픽스처가 가능한 한 구체적이고 응집되어 있는지 확인하는 일은 테스트의 본질을 이해하는 데 도움이 된다. (테스트가 실패할 때 관련성이 커야 한다.)
• (테스트 데이터의 구성에 중심을 둔) 빌더 패턴을 사용하면 범용 픽스처 작성을 피할 수 있다.

11. 마무리

• 새로운 코드를 작성할 권한이 있다면 단위 테스트가 가능하도록 코드를 작성해야 한다.
• 레거시 클래스에 새로운 동작을 추가해야 한다면?
  • 새로운 클래스를 만들고, 새로운 동작을 추가한 후 단위 테스트 작성
  • 레거시 클래스에서 새 클래스의 인스턴스를 생성해서 메서드 호출
  • 결과적으로 테스트가 불가능한 클래스에 테스트를 작성하지 않아도 된다.
• 소프트웨어 모니터링에 충분히 투자하자. (무엇을 로그로 남겨야 할지, 팀의 그라운드 룰을 정립하자.)