단위테스트 1-3장

단위 테스트 1~3장 (Part 1. 더 큰그림) 내용을 기반으로 하고 있습니다.

---

 

1장 단위테스트의 목표

 

# 단위테스트 현황

논쟁은 '단위 테스트를 작성해야하는가?' 에서 '좋은 단위 테스트를 작성하는 것은 어떤 의미인가?' 로 바뀌었다. 

 

# 단위테스트의 목표

- 소프트웨어 프로젝트의 지속 가능한 성장을 가능하게 하는 것

 

지속가능한 프로젝트 성장을 위해서는 고품질 테스트에만 집중해야한다.

(사람들은 종종 테스트가 많으면 많을 수록 좋다고 생각한다. 하지만 그렇지 않다. 코드는 자산이 아니라 책임이다. 코드가 많아질 수록, 소프트웨어 내의 잠재적인 버그에 노출되는 표면적이 더 넓어지고 프로젝트 유지비가 증가한다.)

 

테스트는 코드의 단위가 아니라 동작의 단위. 즉 문제 영역에 의미가 있는 것. 이상적으로는 비즈니스 담당자가 유용하다고 인식할 수 있는 것을 검증해야한다.  (2장)

 

테스트가 제품 코드의 기능을 무조건 나열하면 안된다. 오히려 애플리케이션 동작에 대해 고수준의 명세가 있어야한다.

이상적으로 이 명세는 프로그래머뿐만 아니라 비즈니스 담당자에게도 의미가 있어야한다. (3장)

 

# 테스트 커버리지

- 코드 커버리지 (원시 코드 라인수)

- 분기 커버리지 (if 문, switch 문 같은 제어 구조)

 

한계에 대해 잘 설명해주심.

커버리지가 낮다는 것은 문제의 징후지만, 커버리지가 높다고 해서 테스트 스위트의 품질이 높은 것은 아니다. 

 

# 테스트의 품질

테스트 스위트의 품질은 어떻게 측정해야하는가?

각 테스트를 하나씩 따로 평가하는 것 뿐.

개인의 판단에 맡겨야한다. 자동으로 확인할 수 없다.

 

하지만 성공적인 테스트 스위트는

- 개발 주기에 통합돼 있다.

- 코드베이스에서 가장 중요한 부분만을 대상으로 한다.

- 최소한의 유지비로 최대의 가치를 끌어낸다. 

 

 

2장 단위테스트란 무엇인가

 

# 고전파와 런던파(mock 추종자)

 

두개의 단위 테스트 분파가 있다. (고전파와 런던파)

1. 무엇이 단위를 의미하는 지에 대한 관점

2. 테스트 대상 시스템 (SUT)의 의존성 처리 방식

이 다르다. 

 

 

런던파는 협력자를 격리하고

고전파는 단위테스트 끼리 격리한다.

 

런던파는 하나의 클래스가 여러 클래스에 의존하면 이 모든 의존성을 테스트 대역 (test double) 로 대체해야함.

고전파는 협력자를 대체하지 않고 운영용 인스턴스를 사용.

 

런던파에게 단위테스트는

- 작은 코드 조각을 검증하고

- 빠르게 수행하고

- 격리된 방식으로 처리한다. 

 

고전파에게 단위테스트는

- 단일 동작 단위를 검증하고

- 빠르게 수행하고

- 다른 테스트와 별도로 처리한다.

 

 

# 통합테스트

통합테스트는 단위테스트의 기준 중 하나를 충족하지 않는 테스트.

엔드투엔드테스트 (모든 외부 애플리케이션을 포함해 시스템을 최종 사용자의 관점에서 검증하는 것) 는 통합테스트의 일부. 

 

 

참고로 저자는 고전파에 가까우시며 런던파의 문제, 오해를 잘 설명해주신다. 

런던파로 테스트 많이 해서 그런지 저자의 주장이 신선하고 좋았다. 

 

 

3장 단위 테스트 구조

 

# 검증 구절에는 검증문이 얼마나 있어야하는 가

단위 테스트의 단위는 동작의 단위이지 코드 단위가 아니다.

단일 동작 단위는 여러 결과를 낼 수 있으며, 하나의 테스트로 그 모든 결과를 평가하는 것이 좋다.

그럼에도 검증 구절이 너무 커지는 것은 경계해야한다. 제품코드에서 추상화가 누락됐을 수 있다. 예를들어 클래스 내에 적절한 equality member를 정의하는 것이 좋다. 그러면 단일 검증문 사용가능하다. 

 

# 단위테스트 명명법

https://eunjin3786.tistory.com/563

단위테스트 네이밍 안티패턴

 

# 매개변수화된 테스트

동작의 복잡도가 클 수록 충분히 설명하려면 많은 사실이 필요하다.

각 사실을 테스트로 표현한다. (사실들을 '테스트 셋' 또는 '테스트 메서드에 대한 입력 값 집합' 이라고 할 수 있음)

테스트 코드의 양을 줄이고자 이러한 테스트를 하나로 묶어 매개변수화된 테스트라는 기능을 쓴다. (xUnit에 있는)

 

이는 비용이 발생한다. 테스트 메서드가 나타내는 사실을 파악하기 어려워졌다. 매개변수가 더 많을 수록 어렵다.

절충안으로는 긍정적인 테스트 케이스 / 부정적인 테스트를 각각 두는 것.

긍정적인 테스트 케이스는 고유한 테스트로 도출하고 가장 중요한 부분을 잘 설명하는 이름을 쓰면 좋다. 

 

만약 동작이 너무 복잡하면 매개변수화된 테스트를 조금도 사용하지 말라.