구현 세부 사항을 테스트해서는 안 됩니다.

프론트엔드에서 구현 세부 사항을 테스트하는 개발자를 매우 자주 봅니다. 이것이 왜 나쁜 생각입니까?

이 게시물에서 나는 프런트엔드의 단위 테스트를 언급하고 있습니다. 구현 세부 사항을 테스트하는 것이 타당할 수 있는 다른 특정 사례가 있습니다. 이에 대한 자세한 내용은 하단의 리소스를 확인하세요.

테스트를 유지하기가 더 어려워집니다.

다음 기능이 있다고 상상해보십시오.

function multiply(x, y) {
  let total = 0;
  for (let i = 0; i < y; i++) {
    total = add(total, x);
  }
  return total;
}

function add(total, quantity) {
  return total + quantity;
}

그런 다음 다음과 같은 테스트가 있습니다.

test("returns the correct result", () => {
  expect(multiply(5, 3)).toEqual(15);
});

test("calls the add function the correct number of times", () => {
  multiply(5, 3);
  expect(add).toHaveBeenCalledTimes(3);
});

첫 번째 테스트에서는 메서드의 출력이 올바른지 확인합니다. 그러나 두 번째 테스트에서는 구현 세부 사항을 테스트하고 있습니다. 나중에 누군가 와서 우리 기능을 다음과 같이 업데이트하면:

function multiply(x, y) {
  return x * y;
}

첫 번째 테스트는 통과하지만 두 번째 테스트는 실패합니다. 함수는 여전히 잘 작동하며 출력은 예상한 것입니다. 그러나 여전히 테스트 중 하나가 거짓 음성을 반환하기 때문에 테스트를 업데이트해야 합니다.

이 때문에 우리는 테스트에 의존할 수 없습니다. 리팩토링이 올바른지 여부를 알 수 있다고 확신할 수 없습니다.

다른 사용자가 코드를 사용하는 방식으로 코드를 테스트해야 합니다. React 구성 요소를 테스트하는 경우 사용자가 무엇을 얻을 수 있는지 확인해야 합니다. 라이브러리인 경우 테스트는 다른 앱에서 라이브러리를 사용하는 방식과 유사해야 합니다.

코드의 출력을 테스트함으로써 우리는 소프트웨어의 코드 품질을 개선한 결과로 개발자 경험을 개선합니다.

리팩터링 후에도 코드가 여전히 작동하는지 여부를 쉽게 알 수 있습니다.

자원

Testing Implementation Details

Why You Should Sometimes Test "Implementation Details"