[컴파일 및 공유] Node.js에서 사용할 수 있는 테스트 프레임워크 몇 가지

Node어떤 테스트 프레임워크를 사용할 수 있나요? 다음 기사에서는 몇 가지 Node.js 테스트 프레임워크를 공유할 것입니다. 이것이 도움이 되기를 바랍니다.

편집자 주: 이 기사의 저자는 Ant Group Node.js의 엔지니어인 Tianzhu입니다. 먼저 각 부분에서 일반적으로 사용되는 클래스 라이브러리를 소개하겠습니다. 단위 테스트가 필요한지 논의해 보세요. 함께 논의해 보세요.

일반적으로 사용되는 클래스 라이브러리 및 도구

Test Case Executor

mocha 및 jest가 더 일반적으로 사용됩니다. 공식적인 새로운 노드 테스트는 아직 다듬어지고 있으며 미래는 밝습니다.

$ mocha

  test/egg-view-ejs.test.js
    render
      ✓ should render with locals
      ✓ should render with cache
      ✓ should render with layout
      ✓ should render error
    renderString
      ✓ should renderString with data
      ✓ should renderString error

  6 passing (398ms)

런너가 너무 많아도 출력 기준은 모두 TAP 형식으로 되어 있고 결과는 각기 다른 리포터를 통해 출력됩니다.

커버리지 통계

단일 테스트를 작성하는 것만으로는 충분하지 않습니다. 코드의 모든 분기 프로세스가 커버되는지 알아야 하므로 일반적으로 코드 커버리지 도구를 사용해야 합니다.

이전에는 istanbuljs였는데 나중에 작성자가 nyc로 다시 썼습니다. 그들은 주로 두 가지 책임을 집니다. 하나는 코드를 번역하여 파일링 코드를 삽입하는 것이고, 다른 하나는 다양한 기자가 취재를 생성하도록 지원하는 것입니다. 보고서.

나중에 V8 내장 커버리지 통계

즉, 더 이상 코드를 번역할 필요가 없으며 커버리지 데이터 수집이 기본적으로 지원됩니다.

그런 다음 이 저자는 취재 보고서 생성에 중점을 둔 c8을 썼습니다.

Assert 클래스 라이브러리

변수 결과를 검증하려면 Assert가 필수입니다.

역사에는 expect.js, should.js, chai 및 power-assert이 있으며, jest에도 자체 기대 기능이 내장되어 있습니다.

하지만 이제 Node.js의 공식 assert/strict은 실제로 꽤 좋습니다.

그 중 power-assert는 EggJS에서 항상 사용하고 있는 것입니다. 저도 몇 년 전에도 사용했습니다. "아마도 최고의 JS Assert 라이브러리 - The Emperor's New Clothes".

const assert = require('power-assert');

describe('test/showcase.test.js', () => {
  const arr = [ 1, 2, 3 ];

  it('power-assert', () => {
    assert(arr[1] === 10);
  });
});

// output:
4) test/showcase.test.js power-assert:

      AssertionError:   # test/showcase.test.js:6

  assert(arr[1] === 10)
         |  |   |
         |  2   false
         [1,2,3]

  [number] 10
  => 10
  [number] arr[1]
  => 2

PS: 파일 내용을 확인하고 싶으시다면 assert-file도 작성해 두었습니다. ​​어서 사용해 보세요.

Mock & Stub 클래스 라이브러리

단위 테스트이기 때문에 환경이나 다운스트림 응답을 시뮬레이션해야 하는 경우가 많습니다.

sinonjs도 나쁘지 않고, 모의 및 스텁 등을 지원합니다. jest에는 자체 모의 라이브러리도 내장되어 있습니다.

HTTP 테스트인 경우 nock은 매우 강력하며 서버 응답을 모의하는 데 도움이 될 수 있습니다.

nock('http://www.example.com')
  .post('/login', 'username=pgte&password=123456')
  .reply(200, { id: '123ABC' })

그러나 공식 Node.js undici 요청 라이브러리에도 Mock 기능이 내장되어 있습니다.

스냅샷이라는 용어도 있는데, 이는 작업 중에 데이터를 덤프하고 다음 테스트의 모의 데이터로 직접 사용한다는 의미로, 테스트 작성 효율성을 어느 정도 향상시킬 수 있습니다.

HTTP 테스트 라이브러리

HTTP 서버 시나리오를 테스트하려면 supertest 라이브러리가 필수적입니다.

describe('GET /users', function() {
  it('responds with json', async function() {
    return request(app)
      .get('/users')
      .set('Accept', 'application/json')
      .expect('Content-Type', /json/)
      .expect(200)
      .then(response => {
        assert(response.body.email, 'foo@bar.com');
      });
  });
});

명령줄 테스트 라이브러리

Node.js의 사용 시나리오 중 하나는 Webpack, Babel 등과 같은 명령줄 CLI이며, 자체적으로 단위 테스트도 필요합니다.

이 권장 사항은 우리가 작성한 것입니다:

• GitHub - node-modules/clet: 명령줄 E2E 테스트

• GitHub - node-modules/coffee: Node.js에서 명령줄 테스트

  import { runer, KEYS } from 'clet';

  it('보일러플레이트와 함께 작동해야 합니다.', async () => { 주자를 기다립니다() .cwd(tmpDir, { 초기화: true }) .spawn('npm 초기화') .stdin(/name:/, 'example') // stdout을 기다린 후 응답합니다. .stdin(/version:/, new Array(9).fill(KEYS.ENTER)) .stdout(/"name": "example"/) // stdout 유효성 검사 .notStderr(/npm ERR/) .file('package.json', { name: 'example', version: '1.0.0' }) // 파일 유효성 검사 });

웹 페이지 자동화 테스트 도구

페이지를 가볍게 크롤링하여 HTTP 요청 라이브러리를 직접 사용할 수 있으며 undici를 권장합니다.

브라우저의 실제 실행을 시뮬레이션하기 위해 초기에는 selenium 및 phantomjs이었습니다.

그런 다음 Google은 공식적으로 puppeteer를 출시했습니다. Chromium의 축적으로 인해 devtools-protocol 프로토콜을 기반으로 하여 빠르게 인기를 얻었고 처음 두 가지를 죽였습니다. 유사한 경쟁 제품으로는 playwright 및 cypress가 있습니다.

그런데 macacajs는 브라우저 외에도 모바일 앱 및 데스크톱 앱 테스트도 지원하는 다중 터미널 테스트 도구입니다. Yuque 팀의 엔지니어가 오픈소스로 제공합니다.

지속적 통합 서비스

오픈소스를 작성할 때 테스트를 돕기 위해 자동화된 지속적 통합 서비스가 필요한 경우가 많습니다.

이 분야의 플레이어로는 Travis, Appveyor, GitHub Actions 등이 있습니다.

이제는 기본적으로 GitHub Actions를 사용하는데 통합 수준이 너무 멋집니다.

토론: 단위 테스트가 필요한가요?

단위 테스트가 매우 중요하다는 것은 의심의 여지가 없습니다. 자격을 갖춘 프로그래머에게 필요한 능력이자 전문적인 자질입니다.

물론 우리는 100% 커버리지 매니아는 아니지만 많은 경우 ROI의 균형점을 추구해야 합니다.

1. 단위 테스트 작성은 시간 낭비인가요?

먼저 일반적인 신입생의 관점을 바로잡겠습니다. 단위 테스트 작성이 시간 낭비인가요?

사실 단위 테스트를 작성하면 시간이 절약됩니다. 이렇게 반직관적인 관점을 갖는 이유는 비교 조건이 객관적이지 않은 경우가 많기 때문입니다. 동일한 품질 요구 사항에서 코드를 두 번 수정한 후 회귀 비용을 고려해야 합니다.

공정한 비교를 위해 "단일 테스트 작성 시간"을 고려하는 것 외에도 쉽게 간과되는 것은 "각 코드 수정 후 회귀 테스트 시간"입니다.

• 단일 테스트를 작성할 때 다양한 생성 초기 단계의 분기 모의, 회귀 테스트 시간은 키보드를 입력하는 것뿐입니다.
• 단일 테스트를 작성하지 않고 애플리케이션에 코드를 업데이트한 다음 브라우저 열기와 같은 테스트할 다양한 상황을 수동으로 시뮬레이션해야 합니다. 다양한 곳을 클릭해 보세요.

이 두 가지가 얼마나 시간을 소모하는지 한눈에 알 수 있습니다.

초기 투자비 + 유지비 + 반품 품질 강조에 지나지 않습니다. 회사마다 무게를 따져본 후 결정을 내리는 기준이 있습니다.

물론 제가 언급한 시나리오 중 상당수는 프레임워크 라이브러리(프런트엔드 및 Node.js 포함), 서버측 애플리케이션, 명령줄 도구 등입니다. 크게 변경된 응용 프로그램 또는 빠른 응용 프로그램, 업 및 다운 활동 페이지에 해당하는 단일 테스트 유지 관리 비용은 실제로 매우 높습니다. 현재 ROI를 기반으로 일부 비핵심 분기의 단일 테스트를 적절하게 포기하는 것이 합리적입니다.

그러나 이것이 최후의 수단이라는 점을 이해해야 합니다. 다양한 수단을 통해 단위 테스트의 유지 관리 비용을 줄일 수 있지만 단위 테스트가 쓸모없다고 주장할 수는 없습니다.

프런트 엔드 필드에는 diff를 기반으로 비교를 자동화한 다음 소유자에게 변경 사항의 영향에 주의를 기울이도록 상기시키는 반자동 회귀 테스트도 있습니다. 이는 단일 테스트 작성 비용을 줄이는 데 도움이 되는 위의 도구 라이브러리와 같습니다.

2. 단위 테스트는 프로그래머가 작성하면 안 되나요?

이것도 잘못된 견해입니다. 단위 테스트는 프로그래머가 직접 작성해야 합니다. 이는 자신의 코드이고 책임을 져야 하는 일종의 전문성입니다. 약간의 표준화가 이루어진 팀은 코드를 제출할 때 CI 테스트를 받아야 합니다. 그렇지 않으면 품질 좋은 코드 검토 협업이 이루어지지 않습니다.

수험생은 통합 테스트, 회귀 테스트, 엔드투엔드 테스트 등을 담당합니다. 대규모 작업.

분업이 다르니 남 탓하지 마세요.

그래서...

단위 테스트는 매우 필요합니다. 단위 테스트를 작성하는 것은 프로그래머의 기본 전문 품질입니다. 개별 시나리오에서는 ROI를 기반으로 선택할 수 있습니다.

노드 관련 지식을 더 보려면 nodejs 튜토리얼을 방문하세요!

위 내용은 [컴파일 및 공유] Node.js에서 사용할 수 있는 테스트 프레임워크 몇 가지의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!