• RTL은 테스트를 위한 가상 돔을 제공한다.
• 브라우저없이 테스트를 진행하면 클릭 요소와 같은 작업을 할 때 가상 돔이 필요하다.
• 그리고 가상 돔이 원하는대로 작동하는지 확인 가능
• DOM과 상호 작용하기 위한 유틸리티도 제공한다. 예를 들어, DOM에서 요소를 찾을 수 있거나 클릭과 같은 요소와 상호 작용할 수 있다.
• 브라우저 없이도 테스트 가능하게 한다.

• 테스트를 찾고 실행하는 것과 테스트 통과 여부를 결정하는 역할을 한다.

테스트 할 때는 npm test 라는 명령어로 하면 된다. npm test는 Jest에서 Watch 모드 실행으로 시작한다.

여기서 테스트할 것은 a를 입력하면 a에 관한 테스트 결과가 나온다.

테스트 성공 ! 했다는 뜻이다. src/App.test.js 파일이 테스트 파일이다. q를 입력하면 jest의 Watch 모드가 종료된다.

import { render, screen } from "@testing-library/react";
import App from "./App";

test("renders learn react link", () => {
  render(<App />);
  const linkElement = screen.getByText(/learn testing library/i);
  expect(linkElement).toBeInTheDocument();
});

위 코드가 npm test를 실행했을 때 실행되던 테스트다. 위 코드를 한 줄 한 줄 살펴보자!

• render : 테스트 함수에서는 첫 번째로 이 render라는 메서드를 실행한다. render 메서드는 인수로 제공하는 JSX에 관한 가상돔을 생성한다. (= 컴포넌트)
• screen.getByText : 메서드를 실행하며 표시되는 모든 텍스트를 기반으로 DOM에서 요소를 찾는다.
• (/learn react/i) : geyByText의 인수는 정규 표현식이다. App.js 파일 안에

이렇게 learn react 이 단어가 없으면 테스트는 실패된다.

실패된 모습

• expect(linkElement).toBeInTheDocument(); : Jest의 단언이다. 단언은 테스트 성공과 실패의 원인이다. 복잡하면서도 중요하다.

테스트의 통과 여부를 결정한다. Jest에서 전역 메서드인 expect 메서드로 시작한다. 그리고 인수가 있는데, 인수는 단언이 단언하는 것으로 예측에 들어맞는지 확인하기 위해 Jest에서 확인한다.

이것은 CRA와 제공되며 CRA와 함께 설치된다. setupTests.js 파일을 사용해 각 테스트 전에 jest-dom을 가져온다. 즉, 모든 테스트에서 jest-dom 매처를 사용할 수 있는 것이다.

테스트 러너가 필요하다. 테스트를 찾고 실행하며 단언할 무언가가 필요. -> 이때 Jest를 사용한다.
Jest가 유일한 테스트 러너는 아니다.
Mocha나 Jasmine(제스민)도 있지만, 테스팅 라이브러리에서 Jest를 권장하며 CRA와 함께 제공된다.
그 외에도 효율적이고 사용이 쉽다. npm test를 하면 npm script를 실행했고 그 스크립트가 Jest를 Watch 모드로 실행되게 한다.
pagekage.json 파일에 가면 script가 있는데 test를 실행하면 react-scripts test를 실행하는 것이다.

"scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    📍"test": "react-scripts test",
    "eject": "react-scripts eject"
  },

이면에서는 Jest가 Watch 모드로 실행 중이다.
Watch 모드란? Jest를 실행하는 방법으로 마지막 커밋 이후 파일의 모든 변경 사항을 확인해서 마지막 커밋 이후 변경된 파일과 연관된 테스트만 실행한다.

TDD는 코드 작성 전에 테스트를 작성하고 테스트에 통과하도록 한다!
흔히 레드-그린 테스트라고 한다. 코드 작성 전에 테스트에 실패하는 레드 테스트를 먼저 실행하고 코드 작성 후에 통과하는 테스트로 그린 테스트를 확인하는 것이다.

1. 보통 테스트를 작성하기 전에 약간의 코드를 작성하여 테스트에 오류가 발생하지 않도록 한다.
2. 함수를 작성하거나 함수형 리액트 컴포넌트를 작성한다.
3. 작성시 아무런 이벤트를 발생시키지 않는 빈 함수를 작성한다.
4. 테스트를 작성하면, 함수가 아무것도 하지않기 떄문에 테스트는 실패할 것이다.
5. 코드를 작성해서 테스트에 통과한다.
6. 테스트에 실패시 빨간색으로 표시, 성공시 녹색으로 표시된다.

1. 테스트를 작성하는 것이 프로세스의 한 부분으로 느끼는 방식에 차이가 있다.
2. 코딩 프로세스의 일부이다.
3. 효율적이다. 애플리케이션을 실행하여 원하는대로 작동하는지 확인하면서 소프트웨어를 업데이트 할텐데 이는 수동적인 업데이트이다.
4. 코드 작성 전에 테스트를 작성하면 변경 후에 자동으로 다시 실행할 수 있다.
5. 개발하면서 모든 테스트를 작성해 두면 변경 사항이 생길 때마다 모든 테스트를 다시 실행해서 자동 회귀 테스트를 할 수 있다.
6. 변경 사항 확인을 위해 애플리케이션을 열고 수동으로 테스트할 필요가 없다.

위와 같은 이유들로 테스트 주도 개발인 TDD를 선호하는 것이다.

1. ⭐️유닛(Unit) 테스트⭐️로 보통 함수나 별개의 리액트 컴포넌트 코드의 한 유닛 혹은 단위 테스트를 하는 것이다.
2. ⭐️통합 테스트⭐️는 여러 유닛이 함께 작동하는 방식을 테스트해서 유닛 간의 상호 작용을 테스트하는 것이다.
   ex) 컴포넌트 간의 상호 작용을 테스트하거나 마이크로 서비스 간의 상호 작용을 테스트한다.
3. ⭐️기능 테스트⭐️는 소프트웨어의 특정 기능을 테스트 하는 것이다.

• function은 영어로 함수에서 입력값을 취하고 출력값을 제공하는 소프트웨어 단위를 의미할 수 있고 동작을 의미할 수도 있는데 이 경우에는 동작과 관련한 의미에 해당된다. 특정 코드 함수가 아닌 소프트웨어의 일반적인 동작을 의미한다. 여기서 말하는 일반적인 동작이란 데이터를 폼에 입력하고 제출을 클릭하면 소프트웨어가 특정 데이터 세트로 바르게 작동하는 기능을 확인해야 한다.

여러 유닛이 있는 통합 테스트일 수도 잇지만 유닛 테스트인 기능 테스트일 수도 있다. 입력란에 잘못된 데이터를 입력하면 빨갛게 변하는지 보는 테스트일 수도 ? 유닛 테스트에 가깝지만 여전히 기능 테스트이다. 기능 테스트의 개념은 코드가 아닌 동작을 테스트하는 것이다. 마지막은 인수 테스트 혹은 E2E (End to End) 테스트로 실제 브라우저가 필요하고 애플리케이션이 연결된 서버가 필요하다. 보통 Cypress나 Selenium과 같은 특별한 도구가 필요하다. 다른 도구들도 있지만 이 두 가지가 가장 인기가 많다. 그리고 이 테스트는 RTL을 위해 설계된 테스트가 아니다.

• 테스트를 최대한 격리 시킨다.

  그래서 함수나 컴포넌트를 테스트할 때 의존성을 표시한다. 즉, 다른 의존성이 있거나 컴포넌트가 의존하는 다른 함수가 있다면 실제 버전 대신 테스트 버전을 사용한다. 따라서, 문제가 발생하거나 테스트 실패 시 생태계의 다른 어떤 것이 아니라 테스트에 실패하게 만드는 특정 유닛이 문제인 것이다.

• 내부 테스트도 진행한다.

  내부 테스트가 필요한 이유는 격리 상태에서 컴포넌트를 테스트하면 때로는 상태의 차이점에 관해서만 테스트하게 되기 때문이다. 이는 애플리케이션 변경 사항을 확인하는 다른 컴포넌트가 없기 때문이다. 그래서 격리된 유닛에서 실패를 쉽고 정확하게 파악할 수 있다. 테스트 코드의 한 유닛에 격리되어 있기 때문에 테스트가 실패하면 어디를 확인해야 하는지 정확하게 알 수 있다.

• 사용자가 소프트웨어와 상호 작용하는 방식과는 거리가 멀다.

  테스트를 통과할 수있다는 뜻. 소프트웨어와 상호 작용하는 사용자가 실패하거나 반대로 사용자가 소프트웨어와 상호 작용하는데 문제가 없어도 테스트에 실패할 수 있다. 사용자가 소프트웨어와 상호 작용하는 방식과는 조금 덜 밀접하게 연결되어 있기 때문이다.

• 테스트를 리팩토링으로 실패할 가능성도 있다.

  리팩토링은 동작을 변경하지 않고 소프트웨어 작성 방식을 변경하는 것으로 보통 유닛테스트로 소프트웨어가 어떻게 작성됐는지 테스트한다. 내부 테스트하는 것임. 작성 방식을 변경하면, 동작이 변경되지 않아도 테스트에 실패할 수 있음을 의미한다. 따라서, 소프트웨어가 제대로 작동하면 테스트도 통과해야 하기 때문에 이런 점은 단점이 된다.

• 유닛 테스트와는 다른 사고방식을 가지고 있다. 테스트하는 특정 동작이나 유저 플로우와 연관된 모든 단위를 포함한다.
• 사용자가 소프트웨어와 상호 작용하는 방식과 밀접하다. 즉, 테스트에 통과하면 사용자에게 문제가 없고 실패하면 문제가 있음.
• 코드 작성 방식을 리팩토링하면 동작이 동일하게 유지되는 한 테스트도 통과하게 된다.

• 실패한 테스트를 디버깅하기 어렵다. 코드가 테스트와 유닛 테스트처럼 밀접하게 연결되어 있지 않아서 어떤 부분의 코드가 실패의 원인인지 찾기가 어렵다.
• 전반적으로 RTL은 기능 테스트의 장점이 단점을 보완한다고 생각

• 테스팅 라이브러리는 사용자의 애플리케이션 사용 방식 테스트를 권장하는데, 이는 행동을 테스트 하는 것이다.
• 매우 명확하다. 다양한 역할 간의 협업이 필요 -> 개발자나 QA, 사업 파트너 등
• 서로 다른 그룹이 상호 작용하는 방식에 관한 프로세스도 정의되어 있다.

참고자료
https://testing-library.com/docs/queries/about/#priority
https://www.w3.org/TR/wai-aria/#role_definitions