🐤 Chapter 4. 좋은 단위 테스트의 4대 요소

🥕 좋은 단위 테스트의 4대 요소 자세히 살펴보기

좋은 단위 테스트에는 다음 네 가지 특성이 있다.

• 회귀 방직
• 리팩터링 내성
• 빠른 피드백
• 유지 보수성

이 네 가지 특성이 기본이다. 이 특성으로 어떤 자동화된 테스트도 분석할 수 있다.

🎈 첫 번째 요소: 회귀 방지

회귀는 소프트웨어 버그다. 코드를 수정한 후 기능이 의도한 대로 작동하지 않는 경우다.

회귀 방지 지표에 대한 테스트 점수가 얼마나 잘 나오는지 평가하려면 다음 사항을 고려해야 한다.

• 테스트 중에 실행되는 코드의 양
• 코드 복잡도
• 코드의 도메인 유의성

일반적으로 실행되는 코드가 많을 수록 테스트에서 회귀가 나타날 가능성이 높다.
코드의 양뿐만 아니라 복잡도와 도메인 유의성도 중요하다. 복잡한 비즈니스 로직을 나타내는 코드가 보일러플레이트 코드보다 훨씬 더 중요하다. 비즈니스에 중요한 기능에서 발생한 버그가 가장 큰 피해를 입히기 때문이다.
반면에 단순한 코드를 테스트하는 것은 가치가 거의 없다. 이러한 코드는 짧고, 비즈니스 로직을 많이 담고 있지도 않다. 단순한 코드를 다루는 테스트는 실수할 여지가 많지 않기 때문에 회귀 오류가 많이 생기지 않는다. 단순한 코드의 예로 다음과 같이 속성 한 줄이 있다.

public class User {
  public string Name { get; set; }
}

게다가 여러분의 코드 외에 작성하지 않은 코드도 중요하다. 이 코드는 작성한 코드만큼이나 소프트웨어 작동에 영향을 미친다. 최상의 보호를 위해서는 테스트가 해당 라이브러리, 프레임워크, 외부 시스템을 테스트 범주에 포함시켜서 소프트웨어가 이러한 의존성에 대해 검증이 올바른지 확인한다.

🎈 두 번째 요소: 리팩터링 내성

좋은 단위 테스트의 두 번째 특성은 리팩터링 내성이다. 이는 테스트를 빨간색(실패)으로 바꾸지 않고 기본 애플리케이션 코드를 리팩터링할 수 있는지에 대한 척도다.

리팩터링으로 정확히 무엇이 고장 났는지를 자세히 살펴봤지만, 알고 보니 아무것도 고장 나지 않았다. 기능은 예전과 같이 완벽하게 작동한다. 문제는 기반 코드를 수정하면 테스트가 빨간색으로 바뀌게끔 작성됐다는 것이다. 그리고 실제로 기능이 작동하지 않는지는 상관없다.

이러한 상황을 거짓 양성이라고 한다. 거짓 양성은 허위 경보다. 실제로 기능이 의도한 대로 작동하지만 테스트는 실패를 나타내는 결과다. 이러한 거짓 양성은 일반적으로 코드를 리팩터링할 때, 즉 구현을 수정하지만 식별할 수 있는 동작은 유지할 때 발생한다.

리팩터링 내성 지표에서 테스트 점수가 얼마나 잘 나오는지 평가하려면 테스트에서 얼마나 많이 거짓 양성이 발생하는지 살펴봐야 한다. 적을수록 좋다.
단위 테스트의 목표는 프로젝트 성장을 지속 가능하게 하는 것이다. 테스트가 지속 가능한 성장을 하게 하는 메커니즘은 회귀 없이 주기적으로 리팩터링하고 새로운 기능을 추가할 수 있는 것이다. 어기에는 두 가지 장점이 있다.

• 기존 기능이 고장 났을 때 테스트가 조기 경고를 제공한다. 이러한 조기 경고 덕분에 결함이 있는 코드가 운형 환경에 배표되기 훨씬 전에 문제를 해결할 수 있다. 운영 환경이었으면 문제를 처리하는 데 훨씬 더 많은 노력이 필요했을 것이다.
• 코드 변경이 회귀로 이어지지 않을 것이라고 확신하게 된다. 이러한 확신이 없으면 리팩터링을 하는 데 주저하게 되고 코드베이스가 나빠질 가능성이 훨씬 높아진다.

거짓 양성은 이 두 가지 이점을 모두 방해한다.

• 테스트가 타당한 이유 없이 실패하면, 코드 문제에 대응하는 능력과 의지가 희석된다. 시간이 흐르면서 그러한 실패에 익숙해지고 그만큼 신경을 많이 쓰지 않는다.
• 반면에 거짓 양성이 빈번하게 테스트 스위트에 대한 신뢰가 서서히 떨어지며, 더 이상 믿을 만한 안전망으로 인식하지 않는다. 즉, 허위 경보로 인식이 나빠진다. 이렇게 신뢰가 부족해지면 리팩터링이 줄어든다. 회귀를 피하려고 코드 변경을 최소한으로 하기 때문이다.

🎈 무엇이 거짓 양성의 원인인가?

테스트에서 발생하는 거짓 양성의 수는 테스트 구성 방식과 직접적인 관련이 있다. 테스트와 테스트 대상 시스템의 구현 세부 사항이 많이 결합할수록 허위 경보가 더 많이 생긴다. 거짓 양성이 생길 가능성을 줄이는 방법은 해당 구현 세부 사항에서 테스트를 분리하는 것뿐이다. 테스트를 통해 SUT가 제공하는 최종 결과를 검증하는지 확인해야 한다. 테스트는 최종 사용자의 관점에서 SUT를 검증해야 하고 최종 사용자에게 의미 있는 결과만 확인해야 한다. 다른 모든 것은 무시해야 한다.

테스트를 구성하기에 가장 좋은 방법은 문제 영역에 대해 이야기하는 것이다. 이러한 테스트가 실패하면, 이야기와 실제 애플리케이션 동작이 서로 거리가 멀어진 것을 의미한다. 이는 테스트 실패 유형 중 유일하게 도움이 되는 유형이다.

다음 예를 살펴보자. 여기서 MessageRenderer 클래스는 머리글, 본문, 바닥글을 포함하는 메시지의 HTML 표현을 생성한다.

public class Message {
  public string Header { get; set; }
  public string Body { get; set; }
  public string Footer { get; set; }
}

public interface IRenderer {
  string Render(Message message);
}

public class MessageRenderer : IRenderer {
  public IReadOnlyList<IRenderer> SubRenderers { get; }
  public MessageRenderer() {
    SubRenderers = new List<IRenderer> {
      new HeaderRenderer(),
      new BodyRenderer(),
      new FooterRenderer(),
    };
  }

  public string Render(Message message) {
    return SubRenderers
      .Select(x => x.Render(message))
      .Aggregate("", (str1, str2) => str1 + str2);
  }
}

MessageRenderer를 어떻게 테스트할 수 있을까? 한 가지 가능한 방법은 이 클래스가 따르는 알고리즘을 분석하는 것이다.

[Fact]
public void MessageRenderer_uses_correct_sub_renderers() {
  var sut = new MessageRenderer();

  IReadOnlyList<IRenderer> renderers = sut.SubRenderers;

  Assert.Equal(3, renderers.Count);
  Assert.IsAssignableFrom<HeaderRenderer>(renderers[0]);
  Assert.IsAssignableFrom<BodyRenderer>(renderers[1]);
  Assert.IsAssignableFrom<FooterRenderer>(renderers[2]);
}

이 테스트는 하위 렌더링 클래스가 예상하는 모든 유형이고 올바른 순서로 나타나는지 여부를 확인한다.

최종 결과가 바뀌지 않을지라도, 테스트를 수행하면 빨간색으로 변할 것이다. 이는 테스트가 SUT가 생성한 결과가 아니라 SUT의 구현 세부 사항과 결합했기 때문이다. 이 테스트는 똑같이 적용할 수 있는 다른 구현을 고려하지 않고 특정 구현만 예상해서 알고리즘을 검사한다.

MessageRenderer 클래스의 상당 부분을 리팩터링하면 테스트가 실패한다. 말하자면, 리팩터링 과정은 애플리케이션의 식별할 수 있는 동작에 영향을 주지 않으면서 구현을 변경하는 것이다. 그리고 변경할 때마다 빨간색으로 변하는 것은 발호 테스트가 구현 세부 사항에 관계돼 있기 때문이다.
이러한 테스트는 앞에서 설명한 모든 단점을 보여준다.

• 회귀 발생 시 조기 경고를 제공하지 않는다.
• 리팩터링에 대한 능력과 의지를 방해한다.

🎈 구현 세부 사항 대신 최종 결과를 목표로 하기

테스트를 깨지지 않고 리팩터링 내성을 높이는 방법은 SUT의 구현 세부 사항과 테스트 간의 결합도를 낮추는 것뿐이다. 즉, 코드의 내부 작업과 테스트 사이의 가능한 한 멀리 떨어뜨리고 최종 결과를 목표로 하는 것이다.

먼저 다음 사항을 확인해야 한다. MessageRenderer에서 얻은 최종 결과는 무엇인가? 메시지의 HTML 표현이다. 그리고 클래스에서 얻을 수 있는 관찰 가능한 결과이기 때문에 이를 확인하는 것이 마땅하다. 이 HTML 표현이 그대로 유지되는 한 정확히 어떻게 생성되는지는 걱정할 필요가 없다. 이러한 구현 세부 사항은 상관없다. 다음 코드는 테스트의 새 버전이다.

[Fact]
public void Rendering_a_message() {
  var sut = new MessageRenderer();
  var message = new Message {
    Header = "h",
    Body = "b",
    Footer = "f"
  };
  string html = sut.Render(message);
  Assert.Equal("<h1><h</h1><b>b</b><i>f</i>", html);
}

이 테스트는 MessageRenderer를 블랙박스로 취급하고 식별할 수 있는 동작에만 신경 쓴다. 결과적으로 테스트는 리팩터링 내성이 부쩍 늘었다. 즉 HTML 출력을 똑같이 지키는 한, SUT의 변경 사항은 테스트에 영향을 미치지 않는다.

이 테스트는 원래 버전보다 크게 개선됐다. 최종 사용자에게 의미 있는 유일한 결과, 즉 브라우저에 메시지가 표시되는 방식을 검증해 비즈니스 요구 사항에 들어맞는다. 이 테스트는 항상 적시에 실패하고 고객에게 영향을 줄 수 있는 애플리케이션 동작의 변경을 알려주므로 개발자가 주의를 기울여야 한다. 이 테스트에 거짓 양성은 거의 없을 것이다.

🥕 첫 번째 특성과 두 번째 특성 간의 본질적인 관계

🎈 테스트 정확도 극대화

코드 정확도와 테스트 결과에 대해서는 올바른 추론(참 음성 / 테스트 통과 / 작동), 2종 오류(거짓 음성 / 테스트 통과 / 고장 / 회귀 방지), 1종 오류(거짓 양성 / 테스트 실패 / 작동 / 리팩터링 내성), 올바른 추론(참 양성 / 테스트 실패 / 고장) 네 가지 결과가 있을 수 있다. 테스트는 통과하거나 실패할 수 있다. 그리고 기능이 잘 작동할 수도 있고 고장 날 수도 있다.

테스트가 통과하고 기본 기능이 의도한 대로 잘 작동하는 상황은 올바른 추론이다. 테스트는 시스템의 상태를 올바르게 유추했다. 작동 기능과 통과 테스트의 조합에 대한 용어로 "참 음성"이라고 한다.

기능이 고장 나서 테스트가 실패해도 올바른 추론이다. 기능이 제대로 작동하지 않으면 테스트가 실패할 것으로 예상하기 때문이다. 이것이 단위 테스트의 핵심이다. 이 상황에 해당하는 용어는 "참 양성"이다.

테스트에서 오류가 발생하지 않으면 문제가 된다. 이는 "거짓 음성"이다. 거짓 음성을 피하는 데 좋은 테스트의 첫 번째 특성인 회귀 방지가 도움이 된다.

기능은 올바르지만 테스트가 여전히 실패로 표시되는 대칭적인 상황이 있다. 이는 "거짓 양성", 즉 허위 경보다. 거짓 양성을 피하는 데 두 번째 특성인 리팩터링 내성이 도움이 된다.

회귀 방지와 리팩터링 내성은 테스트 스위트의 정확도를 극대화하는 것을 목표로 한다. 정확도 지표는 다음 두 가지 요소를 구성된다.

• 테스트가 버그 있음을 얼마나 잘 나타내는가(거짓 음성(회위 방지 영역) 제외).
• 테스트가 버그 없음을 얼마나 잘 나타내는가(거짓 양성(리팩터링 내성 영역) 제외).

테스트 정확도를 향상시키는 방법은 두 가지가 있다. 첫 번째는 분자, 즉 신호(발견된 버그 수)를 증가시키는 것이다. 이는 회귀를 더 잘 찾아내는 테스트로 개선하는 것이다. 두 번째는 분모, 즉 소음(허위 경보 발생 수)을 줄이는 것이다. 이는 허위 경보를 발생시키지 않는 테스트로 개선하는 것이다.

둘 다 매우 중요하다. 경보가 허위로 울리지 않더라도 버그를 찾을 수 없는 테스트는 소용이 없다. 마찬가지로 코드에서 모든 버그를 찾을 수 있더라도 소음이 많이 발생하면 테스트의 정확도는 0에 가까워진다. 이렇게 찾아도 온통 쓸데없는 정보가 돼버린다.

🎈 거짓 양성과 거짓 음성의 중요성: 역학 관계

프로젝트가 성장함에 따라 거짓 양성은 테스트 스위트에 점점 더 큰 영향을 미치기 시작한다.

초기에는 왜 거짓 양성이 중요하지 않은가? 리팩터링은 바로 중요하지는 않으며, 시간이 지나면서 점차 중요해진다.
리팩터링이 점점 더 필요해짐에 따라 테스트에서 리팩터링 내성도 점점 더 중요해진다.

(특히 프로젝트 후반에) 거짓 양성으로부터 코드를 보호하는 것이 중요해도, 이렇게 거짓 양성을 신경 쓰는 개발자는 거의 없다. 대부분 좋은 단위 테스트의 첫 번째 특성인 회귀 방지에만 중점을 두는 경향이 있는데, 회귀 방지는 프로젝트 성장을 유지하는 데 도움이 되고, 가치가 있으며, 매우 정확한 테스트 스위트를 구축하기에 충분하지 않다.

물론 그 이유는 후반까지 가는 프로젝트가 훨씬 적다는 데 있으며, 이는 다시 대부분의 프로젝트는 작고 또한 프로젝트가 너무 커지기 전에 개발이 끝나기 때문이다. 따라서 프로젝트에 가득히 쌓이고 모든 리팩터링 작업을 방해하는 잘못된 경보보다 눈에 띄지 않는 버그 문제에 직면한다. 그래서 사람들은 버그에 따라 최적화한다. 중대형 프로젝트에서 작업하면, 거짓 음성(알려지지 않은 버그)과 거짓 양성(허위 경보)에 대해 똑같이 주의를 기울여야 한다.

🥕 세 번째 요소와 네 번째 요소: 빠른 피드백과 유지 보수성

빠른 피드백은 단위 테스트의 필수 속성이다. 테스트 속도가 빠를수록 테스트 스위트에서 더 많은 테스트를 수행할 수 있고 더 자주 실행할 수 있다. 테스트가 빠르게 실행되면 코드에 결함이 생기자마자 버그에 대해 경고하기 시작할 정도로 피드백 루프를 대폭 줄여서, 버그를 수정하는 비용을 거의 0까지 줄일 수 있다. 반면에 느린 테스트는 피드백을 느리게 하고 잠재적으로 버그를 뒤늦게 눈에 띄게 해서 버그 수정 비용이 증가한다. 오래 걸리는 테스트는 자주 실행하지 못하기 때문에 잘못된 방향으로 가면서 시간을 더 많이 낭비하게 된다.

마지막으로 좋은 단위 테스트의 네 번째 특성인 유지 보수성 지표는 유지비를 평가한다. 이 지표는 다음 두 가지 주요 요소로 구성된다.

• 테스트가 얼마나 이해하기 어려운가: 이 구성 요소는 테스트의 크기와 관련이 있다. 테스트는 코드 라인이 적을수록 더 읽기 쉽다. 작은 테스트는 필요할 때 변경하는 것도 쉽다. 물론 단지 라인 수를 줄이려고 테스트 코드를 인위적으로 압축하지 않는다고 가정할 때다. 테스트 코드의 품질은 제품 코드만큼 중요하다. 테스트를 작성할 때 절차를 생략하지 말라. 테스트 코드를 일급 시민(first-class citizen)으로 취급하라.
• 테스트가 얼마나 실행하기 어려운가: 테스트가 프로세스 외부 종속성으로 작동하면, 데이터베이스 서버를 재부팅하고 네트워크 연결 문제를 해결하는 등 의존성을 상시 운영하는 데 시간을 들여야 한다

🥕 이상적인 테스트를 찾아서

좋은 단위 테스트의 4대 특성을 다시 보면 다음과 같다.

• 회귀 방지
• 리팩터링 내성
• 빠른 피드백
• 유지 보수성

테스트 코드를 포함한 모든 코드는 책임이다. 최소한으로 필요한 가치로 임계치를 상당히 높게 설정하고 이 임계치를 충족하는 테스트만 테스트 스위트에 남겨라. 소수의 매우 가치 있는 테스트는 다수의 평범한 테스트보다 프로젝트가 계속 성장하는 데 훨씬 더 효과적이다.

🎈 이상적인 테스트를 만들 수 있는가?

이상적인 테스트는 네 가지 특성 모두에서 최대 점수를 받는 테스트다. 안타깝게도 그런 이상적인 테스트를 만드는 것은 불가능하다. 처음 세 가지 특성인 회귀 방지, 리팩터링 내성, 빠른 피드백은 상호 배타적이기 때문이다. 세 가지 특성 모두 최대로 하는 것은 불가능하다. 셋 중 하나를 희생해야 나머지 둘을 최대로 할 수 있다.

두 특성을 최대로 하는 것을 목표로 해서 한 가지 특성을 희생해 결국 가치가 0에 가까워진 테스트를 몇 가지 예로 살펴보자.

🎈 극단적인 사례 1: 엔드 투 엔드 테스트

엔드 투 엔드 테스트는 많은 코드를 테스트하므로 회귀 방지를 훌륭히 해낸다. 실제로 모든 유형이 테스트 중에서 엔드 투 엔드 트세트가 직접 작성한 코드뿐만 아니라 외부 라이브러리, 프레임워크, 서드파티 애플리케이션 등과 같이 직접 작성하지 않았지만 프로젝트에서 사용하는 코드를 가장 많이 수행한다.

또한 엔드 투 엔드 테스트는 거짓 양성에 면역이 돼 리팩터링 내성도 우수하다. 엔드 투 엔드 테스트는 최종 사용자의 관점에서 기능이 어떻게 동작하는지만 볼 수 있으며, 구현 세부 사항은 최대한 제거했다.

그러나 큰 단점으로는 느린 속도다. 엔드 투 엔드 테스트에만 의존하는 모든 시스템은 피드백을 빨리 받기가 어려울 것이다. 이는 엔드 투 엔드 테스트만으로 코드베이스를 다루기가 불가능한 까닭이다.

이러한 테스트는 회귀 오류와 거짓 양성에 대한 방지를 휼륭히 해내지만 속도가 떨어진다.

🎈 극단적인 사례2: 간단한 테스트

세 번째 특성을 희생해서 나머지 두 속성을 극대화하는 또 다른 예로 "간단한 테스트"가 있다.

public class User {
  public string Name { get; set; } // 이 한 줄은 버그가 있을 것 같지 않다.
}

[Fact]
public void Test() {
  var sut = new User();

  sut.Name = "John Smith";

  Assert.Equal("John Smith", sut.Name);
}

간단한 테스트는 매우 빠르게 실행되고 빠를 피드백을 제공한다. 또한 거짓 양성이 생길 가능성이 상당히 낮기 때문에 리팩터링 내성도 우수하다. 그러나 기반 코드에 실수할 여지가 많지 않기 때문에 간단한 테스트는 회귀를 나타내지 않을 것이다.

심지어 간단한 테스트는 이름만 바꿀 뿐 "동어 반복 테스트"를 불러온다. 이러한 테스트는 항상 통과하거나 검증이 무의미하기 때문에 어떤 것도 테스트한다고 할 수 없다.

간단한 테스트는 우수한 리팩터링 내성과 빠른 피드백을 제공하지만 회귀 방지가 없다.

🎈 극단적인 사례 3: 깨지기 쉬운 테스트

실행이 빠르고 회귀를 잡을 가능성이 높지만 거짓 양성이 많은 테스트를 작성하기가 매우 쉽다. 이러한 테스트를 "깨지기 쉬운 테스트"라고 한다. 이는 리팩터링을 견디지 못하고, 해당 기능이 고장 났는지 여부와 관계없이 빨간색으로 바뀐다.

실행 중이 SQL 문을 검증하는 테스트

public class UserRepository {
  public User GetById(int id) {
    // 
  }

  public string LastExecutedSqlStatement { get; set; }
}

[Fact]
public void GetById_executes_correct_SQL_code() {
  var sut = new UserRepository();

  User user = sut.GetById(5);

  Assert.Equal(
    "SELECT * FROM dbo.[User] WHERE UserID = 5",
    sut.LastExecutedSqlStatement)
}

위 테스트가 버그를 잡을 수 있는가? 가능하다. 예를 들어, 개발자가 SQL 코드 생성을 엉망으로 할 수 있고 UserID 대신 ID로 잘못 사용할 수 있으므로 테스트가 실패해서 이를 지적한다. 그러나 이 테스트가 리팩터링 내성이 좋은가? 절대 그렇지 않다. 다음과 같이 SQL 문을 여러 가지 형태로 변형해도 결과는 모두 같다.

SELECT * FROM dbo.[User] WHERE UserID = 5
SELECT * FROM dbo.User WHERE UserID = 5
SELECT UserID, Name, Email FROM dbo.[User] WHERE UserID = 5
SELECT * FROM dbo.[User] WHERE UserID = @UserID

기능이 계속 작동하지만 SQL 스크립트를 위와 같이 변경하면 테스트는 빨간색으로 바뀐다. 이는 테스트가 SUT의 내부 구현 세부 사항에 결합되는 예다. 이 테스트는 무엇보다 "어떻게"에 중점을 두고 있기 때문에 더 이상의 리팩터링은 막으면서 SUT 구현 세부 사항에 스며들고 있다.

깨지기 쉬운 테스트가 세 번째 부분에 해당하는 것을 보여준다. 이러한 테스트는 빠르게 실행되고 회귀 방지를 훌륭히 해내지만 리팩터링 내성은 거의 없다.

🎈 이상적인 테스트를 찾아서: 결론

좋은 단위 테스트의 처음 세 가지 특성은 상호 배타적이다. 이 세 가지 특성 중 두 가지를 극대화하는 테스트를 만들기는 매우 쉽지만, 나머지 특성 한 가지를 희생해야만 가능하다. 이러한 테스트는 곱셈 규칙으로 인해 가치가 0에 가까워진다. 안타깝게도 세 가지 특성 모두 완벽한 점수를 얻어서 이상적인 테스트를 만드는 것은 불가능하다.

네 번째 특성인 유지 보수성은 엔드 투 엔드 테스트를 제외하고 처음 세 가지 특성과 상관관계가 없다. 엔드 투 엔드 테스트는 관련된 모든 의존성을 설정해야 하므로 일반적으로 크기가 더 크다. 또한 이러한 의존성을 계속 운영하려면 추가적인 노력이 더 들게 된다. 따라서 엔드 투 엔드 테스트는 유지비 측면에서 더 비싼 경향이 있다.

그럼 어떻게 희생을 할까? 회귀 방지, 리팩터링 내성, 빠른 피드백 상호 배타성 때문에 세 가지 특성 모두를 양보할 만큼 서로 조금씩 인정하는 것이 최선의 전략이라고 생각할 수 있다. 그러나 실제로는 리팩터링 내성을 포기할 수 없다. 엔드 투 엔드 테스트만 쓰거나 테스트가 상당히 빠르지 않은 한, 리팩터링 내성을 최대한 많이 갖는 것을 목표로 해야 한다. 따라서 테스트가 얼마나 버그를 잘 찾아내는지(회귀 방지)와 얼마나 빠른지(빠른 피드백) 사이의 선택으로 절충이 귀결된다. 이 선택은 회귀 방지와 빠른 피드백 사이에서 자유롭게 움직일 수 있는 "슬라이더"를 떠올리며 이해할 수 있다. 한 특성에서 얻는 것이 많을수록 다른 특성에서 더 잃게 된다.

리팩터링 내성을 포기할 수 없는 이유는 테스트가 이 특성을 갖고 있는지 여부는 대부분 이진 선택이기 때문이다. 즉, 테스트에 리팩터링 내성이 있거나 없거나 둘 중 하나다. 그 사이에 중간 단계는 거의 없다. 따라서 리팩터링 내성을 조금만 인정할 수는 없다. 결국 리팩터링 내성을 완전히 포기해야 할 것이다. 반면에 회귀 방지와 빠른 피드백에 대한 지표는 조절이 가능하다.

테스트 스위트를 탄탄하게 만들려면 테스트의 불안정(거짓 양성)을 제거하는 것이 최우선 과제다.

🥕 대중적인 테스트 자동화 개념 살펴보기

🎈 테스트 피라미드 분해

테스트 피라미드는 테스트 스위트에서 테스트 유형 간의 일정한 비율을 일컫는 개념이다.

테스트 피라미드는 종종 세 가지 유형의 테슽가 있는 피라미드로 표현한다. 넓을수록 해당 테스트가 많아진다. 층의 높이는 이러한 테스트가 최종 사용자의 동작을 얼마나 유사하게 흉내 내는지 나타내는 척도다. 엔드 투 엔드 테스트가 가장 위에 있고, 이는 사용자 경험에 가장 가깝게 흉내 내는 것을 의미한다. 프라미드 내 테스트 유형에 따라 빠른 피드백과 회귀 방지 사이에서 선택한다. 피라미드 상단의 테스트는 회귀 테스트에 유리한 반면, 하단은 실행 속도를 강조한다. (엔드 투 엔드 테스트 -> 통합 테스트 -> 단위 테스트)

모든 테스트는 거짓 양성을 가능한 한 적게 하는 것을 목표로 해야 한다. 심지어 제품 코드를 직접 작업할 때도 그래야 한다.
테스트 유형 간의 정확한 비율은 각 팀과 프로젝트마다 다르겠지만, 일반적으로 피라미드 형태를 유지해야 한다. 즉 엔드 투 엔드 테스트가 가장 적고, 단위 테스트가 가장 많으며, 통합 테스트는 중간 어딘가에 있어야 한다.

엔드 투 엔드 테스트가 적어야 하는 이유는 곱셈 규칙에 있다. 엔드 투 엔드 테스트는 빠른 피드백 지표에서 매우 낮은 점수를 받는다. 또 유지 보수성이 결여돼 있는데, 이는 크기가 더 큰 편이라 관련 프로세스 외부 의존성을 유지하는 데 노력을 더 들여야 한다. 따라서 엔드 투 엔드 테스트는 가장 중요한 기능(버그를 내고 싶지 않은 기능)에 적용할 때와 단위 테스트나 통합 테스트와 동일한 수준으로 보호할 때만 적용된다. 엔드 투 엔드 테스트를 최소한으로 필요한 가치의 임계치를 넘어서 다른 용도로 사용하면 안 된다. 보통 단위 테스트가 더 안정적이므로 더 많이 있다.

테스트 피라미드에는 예외가 있다. 예를 들어 모든 애플리케이션이 비즈니스 규칙이나 기타 복잡도가 거의 없는 CRUD 작업이라면, 테스트 피라미드는 단위 테스트와 통합 테스트의 수가 같고 엔드 투 엔드 테스트가 없는 직사각형처럼 보일 것이다.

테스트 피라미드의 또 다른 예외는 프로젝트 외부 의존성 하나만 연결하는 API다.

🎈 블랙박스 테스트와 화이트박스 테스트 간의 선택

• 블랙박스 테스트는 시스팀의 내부 구조를 몰라도 시스템의 기능을 검사할 수 있는 소프트웨어 테스트 방법이다. 일반적으로 명세와 요구 사항, 즉 애플리케이션이 어떻게 해야 하는지가 아니라 무엇을 해야 하는지를 중심으로 구축된다.
• 화이트박스 테스트는 정반대다. 애플리케이션의 내부 작업을 검증하는 테스트 방식이며, 테스트는 요구 사항이나 명세가 아닌 소스 코드에서 파생된다.

화이트박스 테스트가 더 철저한 편이다. 소스 코드를 분석하면 외부 명세에만 의존할 때 놓칠 수 있는 많은 오류를 발견할 수 있다. 반면에 화이트박스 테스트는 테스트 대상 코드의 특정 구현과 결합돼 있기 때문에 깨지기 쉽다. 이러한 테스트는 거짓 양성을 많이 내고 리팩터링 내성 지표가 부족하다. 또한 비즈니스 담장자에게 의미가 있는 동작으로 유추할 수 없는데, 회이트박스 테스트가 취약하고 가치를 많이 부여하지 않는다는 강력한 신호다. 블랙박스 테스트는 이와 정반대의 장단점을 제공한다.

	회귀 방지	리팩터링 내성
화이트박스 테스트	좋음	나쁨
블랙박스 테스트	나쁨	좋음

리팩터링 내성은 타협할 수 없다. 즉, 테스트는 리팩터링 내성이 있거나 아예 없다. 따라서 화이트박스 테스트 대신 블랙박스 테스트를 기본으로 선택하라. 모든 테스트가 시스템을 블랙박스로 보게 만들고 문제 영역에 의미 있는 동작을 확인하라. 테스트를 통해 비즈니스 요구 사항으로 거슬러 올라갈 수 없다면, 이는 테스트가 깨지기 쉬움을 나타낸다. 이 테스트를 재구성하거나 삭제하라. 기존 테스트 스위트로 두지 말라. 유일한 예외는 알고리즘 복잡도가 높은 유틸리티 코드를 다루는 경우다.

테스트를 작성할 때는 블랙박스 테스트가 바람직하지만, 테스트를 분석할 때는 화이트박스 방법을 사용할 수 있다. 코드 커버리지 도구를 사용해서 어떤 코드 분기를 실행하지 않았는지 확인한 다음 코드 내부 구조에 대해 전혀 모르는 것처럼 테스트하라. 이러한 화이트박스 방법과 블랙박스 방법의 조합이 가장 효과적이다.