비웃는 것은 사악한 것이 아니다!React 테스트 라이브러리를 사용한 더 나은 시뮬레이션

비웃는 것은 사악한 것이 아니다!
그것들은 당신이 더욱 간단하고 탄력적인 테스트를 구축하는 데 도움을 줄 수 있다.이 시리즈에서는 React 구성 요소 시뮬레이션을 작성할 때 사용하는 모드를 보여 드리겠습니다.
다음은 구성 요소 시뮬레이션의 빠른 예입니다.제가 이곳에서 사용하는 것은 jest.mock입니다. 아래에 상세하게 소개하겠습니다.

jest.mock("../src/PostContent", () => ({
  PostContent: jest.fn(() => (
    <div data-testid="PostContent" />
  ))
}))

React 구성 요소 시뮬레이션은 이보다 더 복잡한 것이 없습니다.중요한 것은 아주 간단한 캐시 값 (즉 div 과 data-testid 속성이 있어서 DOM에서 렌더링 실례를 쉽게 찾을 수 있습니다.일반적으로 사용하는 테스트 ID는 항상 어셈블리 이름과 같습니다.이 예에서 이것은 PostContent이다.
우리가 그것을 어떻게 사용하는지 알기 전에, 모크가 무엇인지, 왜 당신이 그것을 사용하려고 하는지 간단하게 돌아봅시다.

무엇이 조롱입니까?
JavaScript 세계에서, 모크라는 단어는 이중 테스트를 나타내는 데 매우 느슨하게 사용된다.테스트 이중 값은 테스트 실행 시 생산 코드의 다른 값을 바꾸는 값일 뿐입니다.그들은 코드의 나머지 부분을 바꾸지 않은 것처럼 실행할 수 있도록 바꿀 대상의 인터페이스를 받아들인다.
네가 이렇게 하려고 하는 이유는 매우 많다.우리는 예시에서 그것들을 소개할 것이다.
만약 네가 복식 총체에 대해 매우 궁금하다면, 나는 네가 마틴 포러의 Mocks Aren't Stubs 를 읽어 보라고 건의한다.

조롱하다
Jest에는 바꿀 모듈 전체를 시뮬레이션할 수 있는 jest.mock라는 함수가 있습니다.JavaScript에서 다른 대체 방법이 있더라도 이 설명서에서 사용하는 내용입니다.

In Mastering React Test-Driven Development I use ES6 named module imports to create test doubles. That approaches gives slightly more flexibility but feels slightly more hacky.

The Jest page on jest.mock 시뮬레이션은 테스트 속도가 빠르고 문제가 발생하지 않도록 확보할 수 있다고 한다.
비록 이것은 사실이지만, 이것은 내가 마크를 사용하는 주요 원인이 아니다.
나는 모크를 사용한다. 왜냐하면 그들은 내가 테스트를 서로 독립시키는 것을 돕기 때문이다.
원인을 이해하기 위해서 예를 하나 봅시다.

왜 비웃어요?
다음은 BlogPage 구성 요소의 목록입니다. id 도구에서 url를 끌어낸 다음 PostContent로 구성 요소를 보여 줍니다.

const getPostIdFromUrl = url =>
  url.substr(url.lastIndexOf("/") + 1)

export const BlogPage = ({ url }) => {

  const id = getPostIdFromUrl(url)

  return (
    <PostContent id={id} />
  )
}

이 구성 요소를 위한 테스트를 계속 작성하고 있다면 모든 테스트가 id 들어갑니다. 이것은 BlogPage.test.js 구성 요소와 BlogPage 구성 요소를 포함하는 단일 테스트 세트입니다.
이 단계에서 당신은 시뮬레이션을 필요로 하지 않습니다. 우리는 아직 PostContent을 보지 못했지만 PostContent의 크기를 고려하면 실제적으로 두 개의 단독 테스트 세트가 필요하지 않습니다. 왜냐하면 BlogPage 대부분은 BlogPage에 불과하기 때문입니다.
상상력을 한층 더 넓히기 위해 현재 가설PostContent과 BlogPage의 기능이 모두 증가하고 있다.천부적인 재능을 가진 개발자로서, 당신은 매일 점점 더 많은 기능을 추가하고 있다.
당신의 테스트를 정상적인 업무 상태로 유지하는 것이 어려워지기 시작합니다.모든 새로운 테스트는 더욱 복잡한 설정을 가지고 있으며, 테스트 세트는 시간 수신기가 되고 있다.이것은 유지해야 할 부담이다.
이것은 흔히 볼 수 있는 문제로, 나는 자주 React 코드 라이브러리에서 그것을 본다.테스트 세트는 가장 간단한 변경이라도 많은 테스트를 중단시킬 수 있다.
이 문제를 해결하는 방법의 하나는 테스트 세트를 분리하는 것이다.우리는 PostContent를 보류하고 새로운 BlogPage.test.js를 만들 것이다. 이것은 PostContent.test.js에 행동을 위한 테스트를 포함해야 한다.기본 사상은 PostContent에 포함된 모든 기능은 PostContent에 지정해야 하고 PostContent.test.js에 포함된 모든 기능(예를 들어 URL 해석)은 BlogPage에 지정해야 한다는 것이다.
네.
그런데 렌더링BlogPage.test.js이 부작용이 있다면?

export const PostContent = ({ id }) => {
  const [ text, setText ] = useState("")

  useEffect(() => {
    fetchPostContent(id)
  }, [id])

  const fetchPostContent = async () => {
    const result = await fetch(`/post?id=${id}`)
    if (result.ok) {
      setText(await result.text())
    }
  }

  return <p>{text}</p>
};

PostContent의 테스트 세트는 부작용을 파악하고 이를 처리할 준비를 해야 한다.예를 들어 응답을 기다리기 위해 줄을 서야 합니다.
우리는 테스트 세트를 분리해서 없애려는 의존성이 여전히 존재한다.
우리의 테스트 조직은 확실히 더 좋지만, 최종적으로 어떠한 변화도 우리의 테스트를 그렇게 약하게 만들지 않는다.
이를 위해 우리는 삭제(또는 모방)BlogPage.test.js가 필요하다.
다음 부분에서 우리는 어떻게 이 점을 할 수 있는지 이해할 것이다.

이게 정말 필요합니까?
겸사겸사 한마디 하자면, 이것은 당신이 단에서 단까지의 테스트 영역에서 단원 테스트 영역으로 진입할 때입니다.

The presence of test doubles is a key indicator that you’re writing unit tests.

많은 경험이 풍부한 테스트 인원들은 즉각 단원 테스트(과 시뮬레이션)를 사용하여 새로운 프로젝트를 시작할 것이다. 왜냐하면 코드 라이브러리가 증가함에 따라 그들은 테스트의 아삭아삭한 문제에 직면하게 될 것이라는 것을 알고 있기 때문이다.
단원 테스트는 종종 끝에서 끝까지의 테스트보다 훨씬 작다.그것들은 매우 작아서 통상적으로 3~4행 코드를 넘지 않는다.이로써 그들은 짝짓기와 통합 프로그래밍 등 소셜코딩 실천의 우수한 후보가 되었다.
단원 테스트를 할 때도 항상 이중 테스트가 필요하지 않습니다. 도구 상자에 있는 또 다른 도구일 뿐입니다. 언제, 어떻게 응용하는지 알아야 합니다.
다음 부분에서