Testing 도구 - FE의 테스트

많은 기업에서 테스트 코드를 작성하고 본인들의 비지니스가 의도대로 작동하는 지 확인하고 테스트 한다.

기존에 SI에서 근무하거나 플랫폼 개발을 할때 기능 구현에 급급해 테스트는 print ,log 로만 확인하고 납품했다.

현재 내가 작업할 항목들은 현재상용중인 완성도가 높은 프로그램이다.

이런 플랫폼을 리뉴얼 하고 개발후 런칭까지 진행을 하게 된다면 기존의 개발 방식 보다 체계적인 무엇인가 필요하다.

해당 프로그램을 배포하고 기존 프로그램에서 새로운 개발 프로젝트로 변경한다는것은 그만큼 높은 완성도를 요구한다.

개발을하면서 최소한의 이슈사항만들기 위해서 내가 진행할 프로젝트에 테스트 프로세스를 반영하는 것이 맞다고 판단.

이번 작성글에선 어떤 테스트 프로세스가 존재하며 어떤 이점이 있는지 알아보며 프로젝트에 반영할 생각이다.

TDD ?

테스트 주도 개발(Test-driven development TDD)의 약자

매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스 중 하나이다.

개발자는 먼저 요구사항을 검증하는 자동화된 테스트 케이스를 작성한다.

그런 후에, 그 테스트 케이스를 통과하기 위한 최소한의 코드를 생성한다. 마지막으로 작성한 코드를 표준에 맞도록 리팩토링한다.

이 기법을 개발했거나 '재발견' 한 것으로 인정되는 Kent Beck은 2003년에 TDD가 단순한 설계를 장려하고 자신감을 불어넣어준다고 말하였다.

Test fail 나는 로직 (Red)

이걸 어떻게든 돌릴수 있게 만든다(yellow)

최종적으로 테스트를 통과(Green)

이런 테스트를 진행하여 로직을 반영 하는 테스트 기법

이점으로는

코드의 효율성( 런타임 속도 )

---

코드 컨벤션 정의

---

리팩토링 , 추가 기능 개발시 테스트 코드 기반으로 사이드 이펙트 방지

---

디버깅

---

Jest or Story Book

Jest / Testing Library / Next Jest 문서 기준으로 세팅을 맞춰 본다.

Jest는 페이스북에서 개발한 Jest는 Test Runner, Test Matcher, Test Mock까지 제공해 주는 All in one 테스팅 프레임워크이다.

이러한 테스팅 도구를 사용하게 되면 작성된 코드가 제대로 동작되는지를 확인할 수 있다. 테스트 코드의 유무는 일종의 보증서 역할을 하기 때문에 프로젝트의 볼륨이 커지는 경우 side-effect를 발견하기 쉬워진다. 또한 잘 작성된 테스트 코드는 기능을 정의한 문서로서의 역할을 할 수 있다.

Next.js Jest 가이드의 moduleNameMapper 예제를 거의 그대로 가져왔다.

install

yarn add @testing-library/user-event @testing-library/react-hooks @testing-library/react @testing-library/jest-dom @testing-library/dom --dev
ts-jest
jest 

package.json

"test": "jest",
"test:watch": "jest --watch"

create

npm init jest@latest

# or

yarn create jest@latest

# or

pnpm create jest@latest

jest.config.js or jest.config.ts

module.exports = {
  collectCoverage: true,
  // on node 14.x coverage provider v8 offers good speed and more or less good report
  coverageProvider: 'v8',
  collectCoverageFrom: [
    '**/*.{js,jsx,ts,tsx}',
    '!**/*.d.ts',
    '!**/node_modules/**',
    '!<rootDir>/out/**',
    '!<rootDir>/.next/**',
    '!<rootDir>/*.config.js',
    '!<rootDir>/coverage/**',
  ],
  testMatch: ['**/*.test.ts'],
  moduleNameMapper: {
    // Handle CSS imports (with CSS modules)
    // https://jestjs.io/docs/webpack#mocking-css-modules
    '^.+\\.module\\.(css|sass|scss)$': 'identity-obj-proxy',
 
    // Handle CSS imports (without CSS modules)
    '^.+\\.(css|sass|scss)$': '<rootDir>/__mocks__/styleMock.js',
 
    // Handle image imports
    // https://jestjs.io/docs/webpack#handling-static-assets
    '^.+\\.(png|jpg|jpeg|gif|webp|avif|ico|bmp|svg)$/i': `<rootDir>/__mocks__/fileMock.js`,
 
    // Handle module aliases
    '^@/components/(.*)$': '<rootDir>/components/$1',
 
    // Handle @next/font
    '@next/font/(.*)': `<rootDir>/__mocks__/nextFontMock.js`,
    // Handle next/font
    'next/font/(.*)': `<rootDir>/__mocks__/nextFontMock.js`,
    // Disable server-only
    'server-only': `<rootDir>/__mocks__/empty.js`,
  },
  // Add more setup options before each test is run
  // setupFilesAfterEnv: ['<rootDir>/jest.setup.js'],
  testPathIgnorePatterns: ['<rootDir>/node_modules/', '<rootDir>/.next/'],
  testEnvironment: 'jsdom',
  transform: {
    // Use babel-jest to transpile tests with the next/babel preset
    // https://jestjs.io/docs/configuration#transform-objectstring-pathtotransformer--pathtotransformer-object
    '^.+\\.(js|jsx|ts|tsx)$': ['babel-jest', { presets: ['next/babel'] }],
  },
  transformIgnorePatterns: [
    '/node_modules/',
    '^.+\\.module\\.(css|sass|scss)$',
  ],
}

세팅후 폴더 생성 테스트 코드 작성

yarn or npm or pnpm

pmpm test 

실행시 

story book

Storybook 공식 “Why Storybook” 요지: UI를 앱과 격리해 스토리로 고정한다.

Storybook은 UI 구성요소와 페이지를 독립적으로 구축하기 위한 프런트엔드 워크숍이다.

웹의 보편성으로 인해 프런트엔드가 더욱 복잡해졌습니다. ( 고려 사항이 많아짐 )

이는 모든 사용자 인터페이스를 하나에서 10, 100, 1000개의 다양한 사용자 인터페이스로 바꾸는 반응형 웹 디자인으로 시작되었습니다. 시간이 지남에 따라 장치, 브라우저, 접근성, 성능 및 비동기 상태와 같은 추가 요구 사항이 쌓였다.

React, Vue, Angular와 같은 구성 요소 기반 도구는 복잡한 UI를 간단한 구성 요소로 분해하는 데 도움이 되지만 만능은 아니다. ( 컴포넌트화 )

프런트엔드가 성장함에 따라 구성요소의 수도 늘어난다. 

성숙한 프로젝트에는 수천 개의 개별 변형을 생성하는 수백 개의 구성 요소가 포함될 수 있습니다. (프로젝트 규모에 따라 컴포넌트 분할과 ui 요소는 당연히 많아질 수밖에 … 😮‍💨)

문제를 더욱 복잡하게 만드는 것은 이러한 UI가 비즈니스 논리, 대화형 상태 및 앱 컨텍스트에 얽혀 있기 때문에 디버깅하기가 어렵다는 것이다.

최신 프런트엔드의 폭이 기존 워크플로를 압도합니다. 개발자는 수많은 UI 변형을 고려해야 하지만 이를 모두 개발하거나 구성할 수 있는 장비는 없다.

 UI를 구축하기가 더 어렵고, 작업 만족도가 낮고, 부서지기 쉬운 상황에 처하게 된다.

이러한 부분을 해결하기 위해 react book을 사용한다

1.기존 프로젝트와 완벽히 격리된 독자적인 UI 구축

2.UI의 변화나 인식을 “스토리”로 캡쳐

반영 자체도 크게 어렵지 않다

프로젝트 root cli 입력

npx storybook@latest init

packgae.json 생성 확인

실행시 StoryBook 프로젝트가 따로 실행되는것 을 볼 수 있다.

테스트의 종류

단위 테스트

통합테스트

인수테스트