Kiểm tra đơn vị JavaScript không có khung

Chọn khung thử nghiệm đơn vị JavaScript là bước đầu tiên cần thiết cho bất kỳ dự án phát triển giao diện người dùng mới nào

Các bài kiểm tra đơn vị rất tốt để yên tâm và giảm lỗi phần mềm. Bạn nên luôn dành thời gian để kiểm tra

Nhưng bạn nên chọn framework nào cho dự án của mình? . com, để giúp bạn quyết định cái nào là tốt nhất cho bạn

Stateofjs thu thập dữ liệu từ hàng nghìn nhà phát triển front-end trong các cuộc khảo sát hàng năm. Đây là bảng xếp hạng gần đây nhất của họ về các khung thử nghiệm JS phổ biến nhất, được sắp xếp theo mức độ sử dụng của chúng. Chúng tôi sẽ xem xét từng cái một và cố gắng hiểu những ưu và nhược điểm của chúng

JavaScript di chuyển nhanh, nhưng các nhà phát triển JavaScript thậm chí còn di chuyển nhanh hơn. Khi JavaScript tiếp tục phát triển, các công cụ mới được giới thiệu và có thể vượt trội so với tổ tiên của chúng. Đó là lý do tại sao chúng ta phải luôn theo dõi các thay đổi và chọn framework phù hợp nhất trong quá trình phát triển của mình.

trong bài này

nói đùa

Được Facebook sử dụng và đề xuất, Jest được hỗ trợ chính thức bởi nhóm nhà phát triển React. Nếu bạn là một lập trình viên dù chỉ trong vài năm, bạn sẽ hiểu tầm quan trọng của việc chọn một framework có cộng đồng mạnh và hỗ trợ tích cực. Khi một công cụ cũng được hỗ trợ bởi một gã khổng lồ như Meta, sẽ có thêm sự thoải mái và yên tâm hơn rất nhiều. Điều này đơn giản có nghĩa là nếu bạn gặp sự cố và không thể tìm ra giải pháp trong tài liệu toàn diện của họ, thì có hàng nghìn nhà phát triển có thể giúp bạn tìm ra vấn đề đó trong vòng vài giờ – nếu không muốn nói là vài phút

mã mẫu

const sum = require(‘./sum’);


test(‘adds 1 + 2 to equal 3’, () => {
  expect(sum(1, 2)).toBe(3);
});
}

ưu

• Hiệu suất. Đối với các dự án nhỏ hơn, ban đầu bạn có thể không lo lắng quá nhiều về điều này, nhưng hiệu suất tăng lên là điều tuyệt vời đối với các dự án lớn hơn muốn triển khai liên tục ứng dụng của họ suốt cả ngày
• khả năng tương thích. Trong khi các nhà phát triển chủ yếu sử dụng Jest để kiểm tra các ứng dụng React, Jest có thể dễ dàng tích hợp vào các ứng dụng khác, cho phép bạn sử dụng các tính năng độc đáo hơn của nó ở nơi khác. Nó tương thích với Angular, Node, Vue và các dự án dựa trên babel khác
• Tự động chế nhạo. Khi bạn nhập lib của mình vào các tệp thử nghiệm, Jest sẽ tự động mô phỏng các thư viện đó để giúp bạn làm việc với chúng dễ dàng hơn và tránh bản mẫu
• API mở rộng. Không giống như các thư viện khác trong danh sách, Jest đi kèm với một API rộng, không yêu cầu bạn thêm các thư viện bổ sung trừ khi bạn thực sự cần
• Chế độ hẹn giờ. Jest có hệ thống mô phỏng Thời gian, rất phù hợp để chuyển tiếp nhanh thời gian chờ trong ứng dụng và giúp tiết kiệm thời gian khi chạy thử nghiệm của bạn
• Phát triển tích cực & Cộng đồng. Jest cải thiện với mỗi bản cập nhật và như đã đề cập trước đây, có cộng đồng tích cực nhất, giúp bạn tiếp cận các giải pháp nhanh chóng khi bạn cần nhất

Nhược điểm

• Thời gian chạy chậm do tự động mô phỏng. Mặc dù tự động mô phỏng đã được coi là một lợi thế trong quá khứ, nhưng nó cũng có thể trở thành tiêu cực từ quan điểm thử nghiệm, vì nó tự động kết thúc tất cả các thư viện của bạn và do đó làm cho các thử nghiệm của bạn chạy chậm hơn một chút

Mocha

Thư viện được sử dụng nhiều thứ hai, Mocha chỉ là một khung thử nghiệm và chỉ cung cấp cho các nhà phát triển cấu trúc thử nghiệm cơ bản. Mocha ban đầu được thiết kế để hoạt động với Node. js, nhưng ngày nay hoạt động trên nhiều khung công tác – bao gồm các khung giao diện người dùng như React, Vue và Angular, miễn là bạn sẵn sàng nhúng tay vào một chút cấu hình

Nó không hỗ trợ các xác nhận, gián điệp và giả lập ngay lập tức nhưng có thể thêm các chức năng này bằng các tiện ích bổ sung/plugin. Lựa chọn thư viện xác nhận phổ biến nhất để ghép nối với Mocha là Chai, nhưng các tùy chọn khác là Khẳng định, Nên. js và khẳng định tốt hơn

mã mẫu

var assert = require(‘assert’);
describe(‘Array’, function () {
  describe(‘#indexOf()’, function () {
    it(‘should return -1 when the value is not present’, function () {
      assert.equal([1, 2, 3].indexOf(4), -1);
    });
  });
});

ưu

• Nhẹ và đơn giản. Đối với các dự án nhỏ hơn không bao gồm các xác nhận phức tạp hoặc logic thử nghiệm, Mocha là một giải pháp đơn giản
• Cấu hình linh hoạt. Nếu bạn muốn cấu hình linh hoạt, bao gồm các thư viện ưa thích của mình, thì thiết lập và cấu hình bổ sung của Mocha là thứ bạn chắc chắn cần kiểm tra
• Hỗ trợ mô-đun ES. Mocha hỗ trợ viết bài kiểm tra của bạn dưới dạng mô-đun ES chứ không chỉ sử dụng CommonJS. (Sử dụng

  var assert = require(‘assert’);
  describe(‘Array’, function () {
    describe(‘#indexOf()’, function () {
      it(‘should return -1 when the value is not present’, function () {
        assert.equal([1, 2, 3].indexOf(4), -1);
      });
    });
  });
  

  0 cùng với sử dụng

  var assert = require(‘assert’);
  describe(‘Array’, function () {
    describe(‘#indexOf()’, function () {
      it(‘should return -1 when the value is not present’, function () {
        assert.equal([1, 2, 3].indexOf(4), -1);
      });
    });
  });
  

  1)

Nhược điểm

• Khó thiết lập hơn. Bạn phải bao gồm các thư viện bổ sung cho các xác nhận và điều này có nghĩa là việc thiết lập khó hơn một chút so với các thư viện khác. Điều đó nói rằng, việc thiết lập nói chung là thỏa thuận một lần, nhưng thật tuyệt khi có thể đề cập đến một “nguồn sự thật duy nhất” (tài liệu) thay vì nhảy khắp nơi trong chương trình
• Khả năng không nhất quán với các plugin. Mocha bao gồm cấu trúc bài kiểm tra dưới dạng toàn cầu, tiết kiệm thời gian bằng cách không phải

  var assert = require(‘assert’);
  describe(‘Array’, function () {
    describe(‘#indexOf()’, function () {
      it(‘should return -1 when the value is not present’, function () {
        assert.equal([1, 2, 3].indexOf(4), -1);
      });
    });
  });
  

  2 hoặc

  var assert = require(‘assert’);
  describe(‘Array’, function () {
    describe(‘#indexOf()’, function () {
      it(‘should return -1 when the value is not present’, function () {
        assert.equal([1, 2, 3].indexOf(4), -1);
      });
    });
  });
  

  1 trong mỗi tệp. Nhược điểm là các plugin có thể yêu cầu bạn bao gồm những thứ này, dẫn đến sự không nhất quán và nếu bạn là người cầu toàn thì điều đó có thể gây khó chịu
• tài liệu yếu hơn. Được biết, tài liệu của Mocha không phải là thế mạnh của nó
• Không hỗ trợ cho bộ chuyển mã tùy ý. Cho đến v6. 0. 0, Mocha có một tính năng cho phép bạn sử dụng một trình chuyển mã tùy ý như coffee-script, v.v., nhưng hiện tại nó không còn được dùng nữa

Quyển truyện

Không giống như các khung kiểm tra JS khác, Storybook là một công cụ kiểm tra giao diện người dùng nhiều hơn. Nó cung cấp một môi trường biệt lập để kiểm tra các thành phần. Câu chuyện giúp dễ dàng khám phá một thành phần trong tất cả các biến thể của nó, bất kể độ phức tạp của nó. Điều đó có nghĩa là các câu chuyện là điểm khởi đầu thiết thực cho chiến lược thử nghiệm giao diện người dùng của bạn. Bạn đã viết các câu chuyện như một phần tự nhiên của quá trình phát triển giao diện người dùng, thử nghiệm những câu chuyện đó là một cách dễ dàng để ngăn lỗi giao diện người dùng theo thời gian. Storybook cũng đi kèm với các công cụ, trình chạy thử nghiệm và tích hợp tiện dụng với hệ sinh thái JavaScript lớn hơn để mở rộng phạm vi kiểm tra giao diện người dùng của bạn

Có nhiều cách bạn có thể sử dụng Storybook để kiểm tra giao diện người dùng

• Các thử nghiệm trực quan chụp ảnh màn hình của mọi câu chuyện, sau đó so sánh nó với các đường cơ sở để phát hiện các vấn đề về giao diện và tích hợp
• Các bài kiểm tra khả năng tiếp cận phát hiện các vấn đề về khả năng sử dụng liên quan đến khuyết tật về thị giác, thính giác, khả năng vận động, nhận thức, lời nói hoặc thần kinh
• Thử nghiệm tương tác xác minh chức năng của thành phần bằng cách mô phỏng hành vi của người dùng, kích hoạt sự kiện và đảm bảo trạng thái đó được cập nhật như mong đợi
• Kiểm tra ảnh chụp nhanh phát hiện các thay đổi trong đánh dấu được hiển thị đối với lỗi hoặc cảnh báo kết xuất bề mặt
• Nhập các câu chuyện trong các thử nghiệm khác vào QA thậm chí nhiều đặc điểm giao diện người dùng hơn

Thật khó để so sánh trực tiếp Storybook với các khung thử nghiệm khác của chúng tôi, vì vậy nếu điều này có vẻ hữu ích cho dự án của bạn, chúng tôi khuyến khích bạn tự nghiên cứu thêm một chút

cây bách

Cypress hoạt động hoàn toàn trong trình duyệt thực (Chrome, Firefox và Edge) mà không cần nhị phân trình điều khiển. Mã tự động và mã ứng dụng chia sẻ cùng một nền tảng và cung cấp cho bạn toàn quyền kiểm soát ứng dụng đang được thử nghiệm. Cypress được biết đến nhiều nhất với khả năng kiểm tra E2E (Từ đầu đến cuối), nghĩa là bạn có thể theo dõi hành vi người dùng được xác định trước và để công cụ này báo cáo các khác biệt tiềm ẩn mỗi khi bạn triển khai mã mới

mã mẫu

describe(‘Actions’, () => {
  beforeEach(() => {
    cy.visit(‘https://example.cypress.io/commands/actions’)
  })

  // https://on.cypress.io/interacting-with-elements

  it(‘.type() – type into a DOM element’, () => {
    // https://on.cypress.io/type
    cy.get(‘.action-email’)
      .type(‘fake@email.com’).should(‘have.value’, ‘fake@email.com’)

      // .type() with special character sequences
      .type(‘{leftarrow}{rightarrow}{uparrow}{downarrow}’)
      .type(‘{del}{selectall}{backspace}’)

      // .type() with key modifiers
      .type(‘{alt}{option}’) //these are equivalent
      .type(‘{shift}’)

      // Delay each keypress by 0.1 sec
      .type(‘slow.typing@email.com’, { delay: 100 })
      .should(‘have.value’, ‘slow.typing@email.com’)

    cy.get(‘.action-disabled’)
      // Ignore error checking prior to type
      // like whether the input is visible or disabled
      .type(‘disabled error checking’, { force: true })
      .should(‘have.value’, ‘disabled error checking’)
  })

  it(‘.focus() – focus on a DOM element’, () => {
    // https://on.cypress.io/focus
    cy.get(‘.action-focus’).focus()
      .should(‘have.class’, ‘focus’)
      .prev().should(‘have.attr’, ‘style’, ‘color: orange;’)
  })
}

ưu

• Thử nghiệm E2E. Vì Cypress được chạy trong một trình duyệt thực nên có thể dựa vào đó để kiểm tra người dùng từ đầu đến cuối
• Kiểm tra ảnh chụp nhanh dòng thời gian. Tại thời điểm thực hiện, Cypress chụp nhanh khoảnh khắc đó và sẽ cho phép nhà phát triển hoặc người kiểm tra QA xem lại những gì đã xảy ra ở một bước cụ thể
• Ổn định và đáng tin cậy. Cypress cho kết quả thực thi thử nghiệm ổn định và đáng tin cậy so với các khung thử nghiệm js khác
• Tài liệu. Từ con số 0 đến khi chạy, Cypress chứa tất cả thông tin cần thiết để giúp bạn tăng tốc. Nó cũng có một cộng đồng thịnh vượng
• Nhanh. Quá trình thực thi thử nghiệm diễn ra nhanh chóng trong Cypress, với thời gian phản hồi dưới 20 mili giây

Nhược điểm

• Không có nhiều trình duyệt. Cypress chỉ có thể chạy thử nghiệm trong một trình duyệt duy nhất

hoa nhài

Jasmine là một khung thử nghiệm phổ biến được sử dụng nổi tiếng như một công cụ phát triển dựa trên hành vi (BDD). BDD liên quan đến việc viết các bài kiểm tra trước khi bạn viết mã thực tế (trái ngược với Phát triển theo hướng kiểm tra (TDD)). Mặc dù Jasmine không chỉ để viết các bài kiểm tra JS và cũng có thể được sử dụng bởi các ngôn ngữ lập trình khác như Ruby (thông qua Jasmine-gem) hoặc Python (thông qua Jsmin-py), nhưng nó đã không còn phổ biến trong những năm qua. Nó không có DOM, có nghĩa là nó không dựa vào trình duyệt để chạy

Mã mẫu

describe(“helloWorld”, () => {
    it(“returns hello world”, () => {
      var actual = helloWorld();
      expect(actual).toBe(“hello world”);
    });
  })

ưu

• API đơn giản. Nó cung cấp một cú pháp rõ ràng và dễ hiểu, cũng như một API phong phú và đơn giản để viết các bài kiểm tra đơn vị của bạn
• Pin cũng bao gồm. Không cần thêm các thư viện xác nhận hoặc mô phỏng — Jasmine có sẵn tất cả chúng. Nhanh. Vì nó không phụ thuộc vào bất kỳ thư viện bên ngoài nào nên nó tương đối nhanh

Nhược điểm

• Ô nhiễm môi trường toàn cầu. Nó tạo Globals thử nghiệm (các từ khóa như “mô tả” hoặc “kiểm tra”) theo mặc định để bạn không phải nhập chúng trong các thử nghiệm của mình. Điều này có thể trở thành một nhược điểm trong các tình huống cụ thể
• Thử nghiệm không đồng bộ đầy thách thức. Kiểm tra các chức năng không đồng bộ hơi khó với Jasmine

nghệ sĩ múa rối

Puppeteer là một thư viện Node được phát triển bởi Nhóm phát triển của Chrome. Đó là một khung để thực thi thử nghiệm, cho phép người dùng điều khiển Chrome không đầu. Mọi thứ bạn có thể thực hiện thủ công trong trình duyệt cũng có thể được thực hiện với Puppeteer

Hầu hết mọi người sử dụng công cụ này để thực hiện một số thử nghiệm khác nhau trên các ứng dụng web như. - Tạo ảnh chụp màn hình và tệp PDF từ trang web - Thu thập dữ liệu trang web - Tự động kiểm tra giao diện người dùng, mô phỏng đầu vào bàn phím và gửi biểu mẫu - Kiểm tra tiện ích mở rộng của chrome

Vì Puppeteer là một trình duyệt không đầu nhưng đầy đủ tính năng nên đây là một lựa chọn lý tưởng để kiểm tra giao diện người dùng của Ứng dụng một trang (SPA)

Mã mẫu

________số 8_______

Thư viện thử nghiệm [React]

Thư viện kiểm tra React không phải là trình chạy thử nghiệm như Jest. Trên thực tế, chúng có thể hoạt động song song. Thư viện thử nghiệm là một bộ công cụ và chức năng giúp bạn truy cập DOM và thực hiện các thao tác trên đó, tức là hiển thị các thành phần thành Virtual DOM, tìm kiếm và tương tác với nó

Theo một số cách, Jest và các khung thử nghiệm truyền thống khác không thể so sánh với Thư viện thử nghiệm. Bạn cần có Jest để có thể thu thập tất cả các tệp kiểm tra có phần mở rộng _______1_______4, chạy từng tệp và hiển thị kết quả đạt/không đạt. So sánh Thư viện thử nghiệm với Enzym hoặc Cypress sẽ chính xác hơn

mã mẫu

import React, {useEffect} from ‘react’
import ReactDOM from ‘react-dom’
import {render, fireEvent} from ‘@testing-library/react’


const modalRoot = document.createElement(‘div’)
modalRoot.setAttribute(‘id’, ‘modal-root’)
document.body.appendChild(modalRoot)

const Modal = ({onClose, children}) => {
  const el = document.createElement(‘div’)

  useEffect(() => {
    modalRoot.appendChild(el)

    return () => modalRoot.removeChild(el)
  })

  return ReactDOM.createPortal(
    <div onClick={onClose}>
      <div onClick={e => e.stopPropagation()}>
        {children}
        <hr />

        <button onClick={onClose}>Close</button>

      </div>

    </div>,

    el,
  )
}

test(‘modal shows the children and a close button’, () => {
  // Arrange
  const handleClose = jest.fn()

  // Act
  const {getByText} = render(
    <Modal onClose={handleClose}>
      <div>test</div>

    </Modal>,

  )
  // Assert
  expect(getByText(‘test’)).toBeTruthy()

  // Act
  fireEvent.click(getByText(/close/i))

  // Assert
  expect(handleClose).toHaveBeenCalledTimes(1)
})

ưu

• Được đề xuất bởi Nhóm phản ứng. Bạn có thể tìm thấy các tài liệu tham khảo và đề xuất để sử dụng thư viện này trong tài liệu của React
• Nhẹ. Vì nó được viết riêng để thử nghiệm các ứng dụng/thành phần React
• Cộng đồng. Thư viện thử nghiệm đang nhận được một số lực kéo thực sự tốt gần đây. Trên thực tế, stackoverflow. số liệu thống kê com đang hiển thị số lượng câu hỏi về Thư viện thử nghiệm đã tăng nhanh hơn enzyme. hình ảnh

Nhược điểm

• Kết xuất không nông. Nó không cung cấp cách để kết xuất “nông cạn” thành phần của bạn mà không có phần tử con của nó, nhưng bạn có thể đạt được điều này bằng cách “mô phỏng” các tính năng của khung thử nghiệm như Jest

WebdriverIO

Webdriver IO là một khung tự động hóa cho các ứng dụng Web và di động. Nó giúp bạn tạo một bộ thử nghiệm cụ thể, có thể mở rộng và ổn định. Sự khác biệt chính giữa WebdriverIO và các ứng dụng khác mà chúng tôi đã giới thiệu trước đó trong bài viết này là nó có thể được sử dụng để kiểm tra các ứng dụng di động lai, gốc và ứng dụng máy tính để bàn gốc cùng với các ứng dụng Web. Trọn gói. WebdriverIO tận dụng sức mạnh của giao thức WebDriver được phát triển và hỗ trợ bởi tất cả các nhà cung cấp trình duyệt và đảm bảo trải nghiệm thử nghiệm trên nhiều trình duyệt thực sự. Nó dựa trên một tiêu chuẩn tự động hóa chung được kiểm tra đúng cách và đảm bảo khả năng tương thích cho tương lai. Tiêu chuẩn này cho phép WebdriverIO hoạt động với bất kỳ trình duyệt nào, bất kể nó được định cấu hình hoặc sử dụng như thế nào

Mã mẫu

it('can handle commands using async/await', async function () {
    const inputElement = await $('#input')
    let value = await inputElement.getValue()
    console.log(value) // outputs: some value
})

ưu

• Đa nền tảng. Nó cho phép chạy thử nghiệm trên máy tính để bàn cũng như trên thiết bị di động
• khả năng tương thích. Hoạt động với nhiều thư viện xác nhận và khung thử nghiệm (Jasmine, Mocha, Cucumber)
• Đơn giản và nhanh chóng. Vì tất cả những lý do trên

Nhược điểm

• Khó gỡ lỗi. Chỉ có thể gỡ lỗi thông qua trình chạy tác vụ WDIO
• Tài liệu. Tại thời điểm viết bài, không có tài liệu tốt nhất và thiếu một số API

nhà viết kịch

Playwright là một khung tự động hóa khác hoạt động tốt nhất cho thử nghiệm E2E. Khung này được Microsoft xây dựng và duy trì và nhằm mục đích chạy trên các công cụ trình duyệt chính – Chromium, Webkit và Firefox

Nó thực sự là một nhánh của một dự án trước đó, Puppeteer (mà chúng tôi đã đề cập ở trên). Sự khác biệt chính là Playwright được viết riêng để thực hiện các thử nghiệm E2E bởi các nhà phát triển và người thử nghiệm. Playwright cũng có thể được sử dụng với các máy chủ CI/CD lớn như TravisCI, CircleCI, Jenkins, Appveyor, GitHub Actions, v.v.

Mã mẫu

import { test, expect } from '@playwright/test';

test('my test', async ({ page }) => {
  await page.goto('https://playwright.dev/');

  // Expect a title "to contain" a substring.
  await expect(page).toHaveTitle(/Playwright/);

  // Expect an attribute "to be strictly equal" to the value.
  await expect(page.locator('text=Get Started').first()).toHaveAttribute('href', '/docs/intro');

  await page.click('text=Get Started');
  // Expect some text to be visible on the page.
  await expect(page.locator('text=Introduction').first()).toBeVisible();
});

ưu

• Được hỗ trợ bởi một công ty đáng tin cậy. Nó được duy trì và hỗ trợ bởi Microsoft
• Đa ngôn ngữ. Playwright hỗ trợ nhiều ngôn ngữ như JavaScript, Java, Python và. MẠNG C#
• Hỗ trợ nhiều người chạy thử nghiệm. Có thể được sử dụng bởi Mocha, Jest và Jasmine
• Qua trình duyệt. Mục tiêu chính của khung này là hỗ trợ tất cả các trình duyệt chính
• Hỗ trợ sự kiện mô phỏng và bản địa. Có thể mô phỏng thiết bị di động, định vị địa lý và quyền. Cũng hỗ trợ khai thác các sự kiện đầu vào gốc cho chuột và bàn phím

Nhược điểm

• Vẫn ở giai đoạn đầu. Nó khá mới và sự hỗ trợ từ cộng đồng còn hạn chế
• Không hỗ trợ thiết bị thực. Không hỗ trợ các thiết bị thực để kiểm tra trình duyệt di động nhưng hỗ trợ trình giả lập

AVA

Một trình chạy thử nghiệm tối giản, AVA tận dụng bản chất không đồng bộ của JavaScript và chạy các thử nghiệm đồng thời, do đó, làm tăng hiệu suất

AVA không tạo bất kỳ Globals nào cho bạn, vì vậy bạn có thể kiểm soát dễ dàng hơn những gì bạn sử dụng. Điều này có thể mang lại sự rõ ràng hơn cho các bài kiểm tra, đảm bảo rằng bạn biết chính xác điều gì đang xảy ra

Mã mẫu

import test from 'ava';

test('foo', t => {
	t.pass();
});

test('bar', async t => {
	const bar = Promise.resolve('bar');
	t.is(await bar, 'bar');
});

ưu

• Chạy thử nghiệm đồng thời. Tận dụng bản chất không đồng bộ của JavaScript làm cho việc kiểm tra trở nên cực kỳ hữu ích. Lợi ích chính là giảm thiểu thời gian chờ đợi giữa các lần triển khai
• API đơn giản. Chứa một API đơn giản chỉ cung cấp những gì bạn cần
• thử nghiệm ảnh chụp nhanh. Được cung cấp qua jest-snapshot, thật tuyệt khi bạn muốn biết khi nào giao diện người dùng của ứng dụng của bạn thay đổi bất ngờ
• Nhấn vào Trình báo cáo. Ava hiển thị một báo cáo có thể đọc được theo mặc định của con người nhưng thật tuyệt khi nhận được báo cáo ở định dạng TAP

Nhược điểm

• Không phân nhóm kiểm tra. Không có cách nào trong Ava để nhóm các bài kiểm tra tương tự lại với nhau
• Không có chế độ chế giễu tích hợp. Ava không đi kèm với chế độ chế nhạo nhưng bạn vẫn có thể sử dụng các thư viện của bên thứ ba cho việc đó (như Sinon. js)

Vitest

Được tạo bởi nhóm đằng sau Vite, Vitest là một trình chạy thử nghiệm gốc cung cấp API tương thích cho phép các nhà phát triển sử dụng nó như một sự thay thế thả xuống của Jest trong hầu hết các dự án

Vitest rất quan tâm đến hiệu suất và sử dụng Worker thread để chạy song song nhiều nhất có thể, mang lại trải nghiệm tốt nhất cho nhà phát triển. Nó vẫn nhẹ bằng cách chọn cẩn thận các phụ thuộc của nó (hoặc trực tiếp nội tuyến các phần cần thiết)

Khung này nhằm mục đích định vị chính nó là Người chạy thử nghiệm được lựa chọn cho các dự án Vite và là một giải pháp thay thế vững chắc ngay cả đối với các dự án không sử dụng Vite. Nhóm đã cung cấp một trang so sánh cho bạn thấy sự khác biệt giữa công cụ này và các công cụ chạy thử nghiệm được sử dụng nhiều nhất như Jest hoặc Cypress

mã mẫu

import { assert, expect, test } from 'vitest'

// Edit an assertion and save to see HMR in action

test('Math.sqrt()', () => {
  expect(Math.sqrt(4)).toBe(2)
  expect(Math.sqrt(144)).toBe(12)
  expect(Math.sqrt(2)).toBe(Math.SQRT2)
})

test('JSON', () => {
  const input = {
    foo: 'hello',
    bar: 'world',
  }

  const output = JSON.stringify(input)

  expect(output).eq('{"foo":"hello","bar":"world"}')
  assert.deepEqual(JSON.parse(output), input, 'matches original')
})

ưu

• Hỗ trợ ESM gốc. Điều đó có nghĩa là bạn có thể hưởng lợi từ hỗ trợ trình duyệt gốc để nhập các mô-đun ESM
• hỗ trợ bản đánh máy. Vitest hỗ trợ cả Typescript và JSX ngay lập tức
• đa luồng. Nó mang đến cho bạn DX tốt nhất với công nhân đa luồng thông qua tinypool
• thử nghiệm trong nguồn. Vitest cung cấp một cách để chạy thử nghiệm trong mã nguồn của bạn cùng với việc triển khai, tương tự như

Nhược điểm

• Trong giai đoạn áp dụng sớm. Mặc dù nhóm đằng sau Vitest đã làm rất tốt trong việc tạo ra công cụ này, nhưng nó vẫn còn non trẻ và sự hỗ trợ của cộng đồng có thể không phải là điều bạn mong đợi

Tổng quan về tiền thưởng

Dưới đây là bảng so sánh bao gồm các đặc điểm chung của tất cả các khung này, để giúp bạn tìm ra khung nào tốt nhất cho trường hợp thử nghiệm cụ thể của bạn

Tôi nên sử dụng khung kiểm tra JavaScript nào?

Sau khi xem xét chỉ một vài trong số rất nhiều khung làm việc ngoài kia, rõ ràng là việc chọn một khung làm việc không phải là trắng đen.

Hầu hết các khung (ngoại trừ Mocha) đều cung cấp các yếu tố cần thiết, đó là môi trường thử nghiệm cùng với các cơ chế để đảm bảo rằng X, Y đã cho luôn được trả về, với một số ít chỉ cung cấp cho bạn thêm “chuông và còi. ” Vì vậy, đối với những điều cơ bản, bạn sẽ cảm thấy khá tự tin khi chọn bất kỳ trong số chúng, với bất kỳ ưu tiên nào khác tùy thuộc vào những gì bạn và dự án cụ thể của bạn muốn và cần

Nếu bạn chưa quen với trò chơi và cần nhiều trợ giúp để bắt kịp tốc độ, bạn nên chọn các khung có cộng đồng mạnh như Jest. Nếu bạn yêu cầu một API rộng cùng với các tính năng cụ thể (có lẽ là duy nhất) thì Mocha là một lựa chọn thông minh, vì khả năng mở rộng là có. Và nếu các thử nghiệm của bạn chủ yếu là E2E, thì bạn có thể chọn giữa Cypress, Puppeteer hoặc Playwright

Cũng xin lưu ý rằng nếu một thư viện mới và không có cộng đồng mạnh vào lúc này, điều đó không có nghĩa là điều này sẽ luôn như vậy. Hãy chắc chắn kiểm tra chúng theo thời gian. Thế giới JavaScript đang thay đổi từng ngày. Hy vọng bài viết này sẽ giúp bạn chọn khung kiểm tra đơn vị JavaScript hoàn hảo vào năm 2022 và hơn thế nữa

Khung kiểm tra có thể giúp bạn cải thiện chất lượng phần mềm và sớm phát hiện lỗi. Để giúp đảm bảo dự án JavaScript của bạn không có lỗi, hãy thêm Giám sát lỗi Raygun vào môi trường thử nghiệm - và sản xuất - của bạn. Dùng thử miễn phí

Bạn có thể kiểm tra đơn vị JavaScript không?

Thử nghiệm đơn vị có phải là một khuôn khổ không?

Jest có tốt cho thử nghiệm đơn vị không?

Có thể viết bài kiểm tra trong nút js mà không cần bất kỳ thư viện bên ngoài nào không?