vitest(테스트 프레임워크) 초우 간단 사용법

당연할꺼당.  React에도 테스트가 존재하련당.

최근에 vitest란게 따사한 눈총을 받고 있당. 편하당. 한번 써 볼까낭 해보장.

 

먼저 사이트에 가서 대략 들러보기 해보장

https://vitest.dev/guide/

 

먼저 vite를 이용해서 리액트 프로젝트를 만들었당 치자.

 

 vitest와 함께 필요한 걸 설치( -D 옵션 알디용!) 

npm i -D vitest
npm i -D happy-dom
npm i -D @testing-library/react
npm i -D @testing-library/jest-dom

happy-dom 은  jest-dom 보다 심플한 상황에서 쉽게 쓸 수 있는 

DOM(Document Object Model) 이당.(지나치면 본 기억이 남는당) 

 

src 폴더에 간단히 아래와 같은 초 간단 파일을 맹글장.

[ 단순히  2개 매개변수 받아서 합을 return 하는 함수당. 그렇당 ]

sum.js

export function sum(a, b) {
  return a + b;
}

 

 

위 sum.js의 sum 함수를 테스트 하는 소스(단위 테스트)를 아래 처럼 맹글장.

[ 보통 파일명.test.확장자,  파일명.spec.확장자 식으로 맹근당. ]

sum.test.js

import { describe, expect, it, test } from "vitest";
import { sum } from "./sum";

// 간단
test("1 + 2는 3이어야짐", () => {
  expect(sum(1, 2)).toBe(3);
});

// it는 test의 alias
it("2 +2 는 4인가?", () => {
  expect(sum(2, 2)).toBe(4);
});

// it는 보통 describe랑(묶음 표현) 잘 사용
describe("머라할거얌", () => {
  it("2 +2 는 4인가?", () => {
    expect(sum(2, 6)).toBe(8);
  });

  test("3 +3 는 6인가?", () => {
    expect(sum(3, 3)).toBe(6);
  });
});

 

이제 터미널에 npx vitest라 쓰고 엔터를 치면 아래와 같은 결과를 보게 된당.

느끼미가 화악하고 순식간에 눈 앞 3cm  거리에 다가서지만 의뭉도 남는당.

describe는 그냥 테스트를 설명하는 문자을 남기기 위해 감싸는 함수라고 생각하공

test와 it는 정확히 같은 의미로 it는 test의 alias당,

보통 describe 안 쓸 때는 test라 쓰고, describe 안에 쓸 때는 it를 주로 쓰는데,

이유는 나역시 모른당. 짐작하는 바가 있지만 지금은 침묵이 가치 있을 듯.. ㅋ

 

결과는 보았지만, 식스센스가 동작 이렇게 형식없이 마구잡이로 쓰진 않을 것 같당.

그렇당.  형식(세팅)이란 걸  쪼메 넣어 보도록 하장. 

 

먼저 npx vitest로 써도 되지만 npm test로 쓰겡 package.json에 아래 내용 추가하장.

package.json

"scripts": {
    "test": "vitest",
    //....생략
 }

 

테스트 환경도 간단히 구성하도록 하장.

vite.config.js

/// <reference types="vitest/config" />
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";

// https://vite.dev/config/
export default defineConfig({
  plugins: [react()],
  test: {
    environment: "happy-dom",
    setupFiles: ["./src/tests/setup.js"],
    include: ["src/**/*.{test,spec}.{js,jsx}"],
  },
});

include 부분은 본인이 한번 추론해서 의미해석 하는 시간을 갖장.

 

위 파일에 정의한 setup.js를  src 아래 tests 폴더 만든 후 아래처럼 만들장.

[ 개별 테스트 실행 후 초기화를 하란 의미당. 그 의미당 ]

setup.js

import { afterEach } from "vitest";
import { cleanup } from "@testing-library/react";
import "@testing-library/jest-dom/vitest";

afterEach(() => {
  cleanup();
});

이제 터미널에 npm test라고 입력후 엔터를 때려보면 같은 결과가 보일거시당.

 

React는 UI 라이브러리다. 그렇다면 UI 를 테스트 해야 한당. 

DOM 동작과 상태를 테스트 해야 할꺼당. 그럴꺼당.

 

아래 처럼 App.jsx를 만들어 보장. (data-testid에 괘니 주목)

App.jsx

import { useState } from "react";

function App() {
  const [insa, setInsa] = useState("안농");
  const handleClick = (e) => {
    setInsa(insa === "안농" ? "나야E7E" : "안농");
  };

  return (
    <>
      <h1 data-testid="insa">{insa}</h1>
      <button data-testid="btn" onClick={handleClick}>
        눌러방
      </button>
    </>
  );
}

export default App;

버튼을 처음 누르면 h1 내용이 안농 에서 나야E7E로 바뀌어야만 한당.(기억!)

 

 

App.jsx의 동작을 테스트하기 위한 App.test.jsx를 아래처럼 맹글장.

App.test.jsx

import { fireEvent, render, screen, waitFor } from "@testing-library/react";
import { describe, it, expect } from "vitest";
import App from "./App";

describe("App Test", () => {
  it("Basic Start", () => {
    render(<App />);
    const insa = screen.getByTestId("insa");

    expect(insa).toBeInTheDocument();
    expect(insa).toHaveTextContent("안농");
    expect(insa.tagName).toBe("H1");
  });

  it("Click Test", async () => {
    render(<App />);
    const btn = screen.getByTestId("btn");
    // fireEvent.change(input, {target: {value:"만세"}})
    fireEvent.click(btn);

    await waitFor(() => {
      const insa = screen.getByTestId("insa");

      expect(insa).toBeInTheDocument();
      expect(insa).toHaveTextContent("나야E7E");
      expect(insa.tagName).toBe("H1");
    });
  });
});

저장하는 순간 터미널에 아래와 같은 화면이 불쑥 놀래킨당.~

소스에 낯선 것이 보이는데, 당신이 똑똑하다면 바로 추론 가능하당.

screen은 화면이당. document로 보면 조금 미심쩍고 UI 컴포넌트(DOM)로 보는 것이 타당

fireEvent는 이벤트를 발생시킨당

await waitFor는 이벤트 핸들러가 끝나기를 기다렸당.

expect 사용법은 이미 추론해서 파악했으리라 믿는당. 이걸로 pass/fail이 결정된당

 

터미널에 q를 입력해서  test watch 모드를  종료하고

다시 npm start 입력 후 엔터를 친다면, 아래 처럼

이전 sum 테스트와 App 테스트가 합쳐진 결과를 얻게 될 꺼이다. 

일부러 fail이 나오는 상황을 만들어 보는 것도 분명 도우미 될꺼이당.

 

사실 보통의 응용개발자들은 단위테스트 프로그램등을 만들면 그 의미가 크게 와 닿지 않는다.

이게 머얌!, 이 정도 동작도 안 하는 거 만들었을까 봥!~~

이거 언제 써용???? ~~  혹 있을지도 모를 당신의 무료한 시간을 위해 남겨두겠당.

 

---

만약에 말야 당신이 감수성 눈물 넘치는 개발자라면 말야...

 

if문을 보고는 머리에.., 만약에 말야, 응 있지 만약에 말야...

 

else if문을 보고는 머리에 또.., 만약에 말야, 이것도... 만약인데 말야...

 

else 문을 보고는 머리에 또, 미안한데 저기 마지막으로 만약인데 말야....

 

저기 만약이지만  만약이라도 저의  if문이 만약 틀려서

 

만약인데 코드는 말도 안되는 데 만약에 결과는 맞는다면

 

만약일지라도 그렇다면....  

 

또 만약 이런 사람들이 만약 엄청나게 많다면..... 

     

 

https://www.youtube.com/watch?v=6FiUjgp1LfY