🔥CHỌN LỌC TOP NHỮNG KHOÁ HỌC LẬP TRÌNH ONLINE NHIỀU NGƯỜI THEO HOC TẠI ĐÂY🔥

Trong hành trình phát triển ứng dụng Vuejs, việc kiểm thử đóng một vai trò vô cùng quan trọng để đảm bảo chất lượng sản phẩm. Với sự phát triển nhanh chóng của cộng đồng phần mềm mở, việc áp dụng các phương pháp kiểm thử hiệu quả càng trở nên cần thiết hơn bao giờ hết. Tại Cafedev, chúng tôi tin rằng việc áp dụng kiểm thử trong quá trình phát triển Vuejs không chỉ giúp tăng cường độ tin cậy cho ứng dụng mà còn giúp đảm bảo tính ổn định và hiệu suất của mã nguồn. Hãy cùng khám phá cách tích hợp kiểm thử vào dự án Vuejs của bạn để tạo ra những ứng dụng vững mạnh và đáng tin cậy nhất!

1. Tại sao cần kiểm thử?

Kiểm thử tự động giúp bạn và nhóm của bạn xây dựng ứng dụng Vue phức tạp một cách nhanh chóng và tự tin bằng cách ngăn ngừa các lỗi trở lại và khuyến khích bạn phân chia ứng dụng thành các hàm, module, lớp và thành phần có thể kiểm thử. Như với bất kỳ ứng dụng nào, ứng dụng Vue mới của bạn có thể gặp phải nhiều vấn đề, và quan trọng là bạn có thể bắt lỗi và sửa chúng trước khi phát hành.
Trong hướng dẫn này, chúng tôi sẽ đề cập đến thuật ngữ cơ bản và đưa ra các đề xuất về các công cụ nào nên chọn cho ứng dụng Vue 3 của bạn.

Dưới đây là một phần đặc biệt về composables trong Vue. Xem Kiểm thử Composables bên dưới để biết thêm chi tiết.

2. Khi nào cần kiểm thử

Bắt đầu kiểm thử sớm! Chúng tôi khuyến khích bạn bắt đầu viết các bài kiểm thử ngay khi có thể. Càng chờ đợi để thêm các bài kiểm thử vào ứng dụng của bạn, ứng dụng của bạn sẽ có nhiều phụ thuộc hơn và sẽ khó khăn hơn để bắt đầu.

3. Các loại kiểm thử

Khi thiết kế chiến lược kiểm thử cho ứng dụng Vue của bạn, bạn nên tận dụng các loại kiểm thử sau:
– Đơn vị: Kiểm tra rằng đầu vào của một hàm, lớp hoặc composables cụ thể đang tạo ra kết quả hoặc hiệu ứng bên.
– Component: Kiểm tra rằng thành phần của bạn được gắn kết, render, có thể tương tác và hoạt động như mong đợi. Những bài kiểm thử này nhập nhiều mã hơn so với các bài kiểm thử đơn vị, phức tạp hơn và yêu cầu thời gian thực thi nhiều hơn.
– Từ đầu đến cuối: Kiểm tra các tính năng lan rộng qua nhiều trang và thực hiện các yêu cầu mạng thực sự đối với ứng dụng Vue đã được

xây dựng cho sản xuất của bạn. Những bài kiểm thử này thường liên quan đến việc triển khai cơ sở dữ liệu hoặc backend khác.
Mỗi loại kiểm thử đều đóng vai trò trong chiến lược kiểm thử của ứng dụng của bạn và mỗi loại sẽ bảo vệ bạn khỏi các loại vấn đề khác nhau.

4. Tổng quan

Chúng tôi sẽ tóm tắt ngắn gọn về mỗi loại này, cách triển khai chúng cho các ứng dụng Vue và đưa ra một số khuyến nghị chung.

5. Kiểm thử Đơn vị

Các bài kiểm thử đơn vị được viết để xác minh rằng các đơn vị mã nhỏ, cô lập hoạt động như mong đợi. Một bài kiểm thử đơn vị thường bao gồm một hàm, lớp, composables hoặc module duy nhất. Các bài kiểm thử đơn vị tập trung vào tính chính xác logic và chỉ quan tâm đến một phần nhỏ của tổng thể chức năng của ứng dụng. Chúng có thể giả mạo các phần lớn trong môi trường ứng dụng của bạn (ví dụ: trạng thái ban đầu, các lớp phức tạp, module bên thứ ba và các yêu cầu mạng).
Nhìn chung, các bài kiểm thử đơn vị sẽ phát hiện ra các vấn đề về logic kinh doanh và tính chính xác logic.

Hãy xem xét ví dụ về hàm increment này:

// helpers.js
export function increment (current, max = 10) {
  if (current < max) {
    return current + 1
  }
  return current
}

Bởi vì nó rất tự chứa, việc gọi hàm increment và khẳng định rằng nó trả về những gì nó cần trả về sẽ dễ dàng, vì vậy chúng ta sẽ viết một Bài kiểm thử đơn vị.
Nếu bất kỳ khẳng định nào thất bại, rõ ràng vấn đề nằm trong hàm increment.


// helpers.spec.js
import { increment } from './helpers'

describe('increment', () => {
  test('increments the current number by 1', () => {
    expect(increment(0, 10)).toBe(1)
  })

  test('does not increment the current number over the max', () => {
    expect(increment(10, 10)).toBe(10)
  })

  test('has a default max of 10', () => {
    expect(increment(10)).toBe(10)
  })
})

Như đã đề cập trước đó, bài kiểm thử đơn vị thường được áp dụng cho logic kinh doanh tự chứa, các thành phần, lớp, module hoặc hàm không liên quan đến việc hiển thị giao diện người dùng, các yêu cầu mạng hoặc các vấn đề môi trường khác.
Thường là các module JavaScript / TypeScript thuần túy không liên quan đến Vue. Nhìn chung, việc viết bài kiểm thử đơn vị cho logic kinh doanh trong các ứng dụng Vue không khác biệt đáng kể so với các ứng dụng sử dụng các framework khác.

Có hai trường hợp mà BẠN phải kiểm thử đơn vị các tính năng cụ thể của Vue:

  1. Composables
  2. Components

Một loại hàm cụ thể cho các ứng dụng Vue là Composables, có thể yêu cầu xử lý đặc biệt trong quá trình kiểm thử. Xem [[L_PLACE1]] phía dưới để biết thêm chi tiết.

5.1 Kiểm thử đơn vị Components

Một thành phần có thể được kiểm thử theo hai cách:
1. Whitebox: Kiểm thử đơn vị


Các bài kiểm thử “Whitebox tests” nhận thức về các chi tiết thực hiện và phụ thuộc của một thành phần. Chúng tập trung vào cô lập thành phần đang được kiểm thử. Những bài kiểm thử này thường liên quan đến việc giả mạo một số, nếu không phải tất cả các thành phần con của thành phần của bạn, cũng như thiết lập trạng thái và phụ thuộc của plugin (ví dụ: Pinia).


2. Blackbox: Kiểm thử thành phần

Các bài kiểm thử “Blackbox tests” không nhận thức về các chi tiết thực hiện của một thành phần. Những bài kiểm thử này giả mạo ít nhất có thể để kiểm tra tích hợp của thành phần của bạn và toàn bộ hệ thống. Thường là render tất cả các thành phần con và được coi là một “kiểm thử tích hợp” hơn. Xem Các khuyến nghị về kiểm thử thành phần phía dưới.

5.2 Đề xuất

  • Vitest
    Vì thiết lập chính thức được tạo ra bởi create-vue dựa trên Vite, chúng tôi khuyến nghị sử dụng một framework kiểm thử đơn vị có thể tận dụng cùng cấu hình và đường ống biến đổi trực tiếp từ Vite. Vitest là một framework kiểm thử đơn vị được thiết kế đặc biệt cho mục đích này, được tạo và duy trì bởi các thành viên trong nhóm Vue / Vite. Nó tích hợp với các dự án dựa trên Vite một cách tối thiểu và rất nhanh chóng.

5.3 Các Lựa Chọn Khác

  • Jest là một framework kiểm thử đơn vị phổ biến. Tuy nhiên, chúng tôi chỉ khuyến nghị Jest nếu bạn có một bộ kiểm thử Jest hiện có cần phải được di chuyển sang một dự án dựa trên Vite, vì Vitest cung cấp một tích hợp mượt mà hơn và hiệu suất tốt hơn.

6. Kiểm thử Thành Phần

Trong ứng dụng Vue, các thành phần là các khối xây dựng chính của giao diện người dùng. Do đó, các thành phần là đơn vị tự nhiên để cô lập khi kiểm tra hành vi của ứng dụng của bạn. Từ góc độ tỷ lệ, việc kiểm thử thành phần đặt ở mức độ cao hơn so với kiểm thử đơn vị và có thể coi là một hình thức của kiểm thử tích hợp. Phần lớn ứng dụng Vue của bạn nên được bao phủ bởi một bài kiểm thử thành phần và chúng tôi khuyến nghị mỗi thành phần Vue có một tệp spec riêng của nó.
Các bài kiểm thử thành phần nên phát hiện các vấn đề liên quan đến các props của thành phần, các sự kiện, các khe cắm mà nó cung cấp, kiểu dáng, các lớp, các hooks lifecycle và nhiều hơn nữa.

Các bài kiểm thử thành phần không nên giả mạo các thành phần con, mà thay vào đó kiểm tra các tương tác giữa thành phần của bạn và các thành phần con của nó bằng cách tương tác với các thành phần như một người dùng. Ví dụ, một bài kiểm thử thành phần nên nhấp vào một phần tử giống như một người dùng thay vì tương tác với thành phần theo cách lập trình.

Các bài kiểm thử thành phần nên tập trung vào giao diện công cộng của thành phần thay vì các chi tiết cài đặt nội bộ. Đối với hầu hết các thành phần, giao diện công cộng giới hạn ở: các sự kiện được phát ra, props, và khe cắm. Khi kiểm thử, hãy nhớ kiểm tra những gì một thành phần làm, không phải cách nó làm.

NÊN

  • Đối với Logic Hiển thị: khẳng định đầu ra hiển thị đúng dựa trên props và khe cắm được nhập vào.
  • Đối với Logic Hành vi: khẳng định cập nhật hiển thị đúng hoặc các sự kiện được phát ra đúng khi phản ứng với các sự kiện người dùng nhập vào.
    Trong ví dụ dưới đây, chúng tôi minh họa một thành phần Stepper có một phần tử DOM có nhãn increment và có thể được nhấp. Chúng tôi truyền một prop gọi là max để ngăn Stepper tăng lên quá 2, vì vậy nếu chúng tôi nhấp vào nút 3 lần, giao diện người dùng vẫn nên hiển thị 2.
    Chúng tôi không biết gì về cách triển khai của Stepper, chỉ biết “đầu vào” là prop max và “đầu ra” là trạng thái của DOM như người dùng sẽ thấy.

Ví dụ về Vue Test Utils:

const valueSelector = '[data-testid=stepper-value]'
  const buttonSelector = '[data-testid=increment]'

  const wrapper = mount(Stepper, {
    props: {
      max: 1
    }
  })

  expect(wrapper.find(valueSelector).text()).toContain('0')

  await wrapper.find(buttonSelector).trigger('click')

  expect(wrapper.find(valueSelector).text()).toContain('1')

Ví dụ về Cypress:

const valueSelector = '[data-testid=stepper-value]'
  const buttonSelector = '[data-testid=increment]'

  mount(Stepper, {
    props: {
      max: 1
    }
  })

  cy.get(valueSelector).should('be.visible').and('contain.text', '0')
    .get(buttonSelector).click()
    .get(valueSelector).should('contain.text', '1')

Ví dụ về Testing Library:

const { getByText } = render(Stepper, {
    props: {
      max: 1
    }
  })

  getByText('0') // Implicit assertion that "0" is within the component

  const button = getByRole('button', { name: /increment/i })

  // Dispatch a click event to our increment button.
  await fireEvent.click(button)

  getByText('1')

  await fireEvent.click(button)

KHÔNG NÊN
Đừng khẳng định trạng thái riêng tư của một thể hiện thành phần hoặc kiểm tra các phương thức riêng tư của một thành phần. Kiểm thử các chi tiết cài đặt làm cho các bài kiểm thử dễ vỡ, vì chúng có khả năng gặp sự cố và cần cập nhật khi cài đặt thay đổi.

Nhiệm vụ cuối cùng của thành phần là hiển thị đầu ra DOM đúng, vì vậy các bài kiểm thử tập trung vào đầu ra DOM cung cấp cùng mức độ đảm bảo đúng (nếu không hơn) trong khi vẫn mạnh mẽ và chịu biến đổi.

Đừng hoàn toàn phụ thuộc vào các bài kiểm thử snapshot. Khẳng định chuỗi HTML không mô tả tính chính xác. Viết các bài kiểm thử một cách có chủ đích.

Nếu một phương thức cần được kiểm thử kỹ lưỡng, hãy xem xét trích xuất nó thành một hàm tiện ích độc lập và viết một bài kiểm thử đơn riêng cho nó. Nếu không thể trích xuất một cách sạch sẽ, nó có thể được kiểm thử như một phần của một thành phần, tích hợp, hoặc kiểm thử end-to-end mà bao gồm nó.

6.1 Khuyến Nghị

  • Vitest cho các thành phần hoặc composables mà hiển thị một cách vô hình (ví dụ: hàm useFavicon trong VueUse). Các thành phần và DOM có thể được kiểm thử bằng @vue/test-utils.
  • Kiểm Thử Thành Phần Cypress cho các thành phần mà hành vi dự kiến phụ thuộc vào việc hiển thị kiểu hoặc kích hoạt các sự kiện DOM nguyên thuỷ. Nó có thể được sử dụng với Thư viện Kiểm Thử thông qua @testing-library/cypress.
  • Các khác biệt chính giữa Vitest và các công cụ chạy dựa trên trình duyệt là tốc độ và ngữ cảnh thực thi. Tóm lại, các công cụ chạy dựa trên trình duyệt, như Cypress, có thể phát hiện các vấn đề mà các công cụ chạy dựa trên node, như Vitest, không thể (ví dụ: vấn đề về kiểu dáng, sự kiện DOM thực, cookie, bộ nhớ cục bộ, và sự cố mạng), nhưng các công cụ chạy dựa trên trình duyệt chậm hơn nhiều lần so với Vitest vì chúng mở một trình duyệt, biên dịch các stylesheet của bạn, và nhiều hơn nữa. Cypress là một công cụ chạy dựa trên trình duyệt hỗ trợ kiểm thử thành phần. Vui lòng đọc trang so sánh của Vitest để biết thông tin mới nhất so sánh giữa Vitest và Cypress.

6.2 Thư Viện Mounting

Kiểm thử thành phần thường liên quan đến việc lắp đặt thành phần được kiểm thử một cách cô lập, kích hoạt các sự kiện đầu vào giả mạo, và khẳng định về đầu ra DOM đã được hiển thị. Có các thư viện tiện ích được dành riêng để làm cho các công việc này đơn giản hơn.

  • @vue/test-utils là thư viện kiểm thử thành phần cấp thấp chính thức được viết để cung cấp quyền truy cập vào các API cụ thể của Vue cho người dùng. Nó cũng là thư viện cấp thấp mà @testing-library/vue được xây dựng dựa trên.
  • @testing-library/vue là một thư viện kiểm thử Vue tập trung vào việc kiểm thử các thành phần mà không phụ thuộc vào các chi tiết triển khai. Nguyên tắc hướng dẫn của nó là càng nhiều bài kiểm thử giống như cách phần mềm được sử dụng, thì sự tự tin mà chúng có thể cung cấp càng cao.
    Chúng tôi khuyến nghị sử dụng @vue/test-utils để kiểm thử các thành phần trong ứng dụng. @testing-library/vue có vấn đề với việc kiểm thử các thành phần bất đồng bộ với Suspense, vì vậy nó nên được sử dụng cẩn thận.

6.3 Lựa Chọn Khác

  • Nightwatch là một công cụ chạy kiểm thử E2E với hỗ trợ Kiểm Thử Thành Phần Vue. (Dự Án Mẫu)
  • WebdriverIO cho kiểm thử thành phần đa trình duyệt dựa trên tương tác người dùng cơ bản dựa trên tự động hóa chuẩn hóa. Nó cũng có thể được sử dụng với Thư Viện Kiểm Thử.

7. Kiểm Thử E2E

Trong khi các bài kiểm thử đơn vị cung cấp cho các nhà phát triển một mức độ tin cậy nhất định, bài kiểm thử đơn vị và thành phần có hạn chế trong khả năng cung cấp phạm vi kiểm tra toàn diện của một ứng dụng khi triển khai vào production. Do đó, các bài kiểm thử end-to-end (E2E) cung cấp phạm vi kiểm tra trên điều mà có thể nói là khía cạnh quan trọng nhất của một ứng dụng: điều gì xảy ra khi người dùng thực sự sử dụng ứng dụng của bạn.

Các bài kiểm thử end-to-end tập trung vào hành vi của ứng dụng nhiều trang, thực hiện các yêu cầu mạng đối với ứng dụng Vue của bạn được xây dựng cho production. Thường thì, chúng liên quan đến việc triển khai một cơ sở dữ liệu hoặc backend khác và thậm chí có thể chạy đối với môi trường staging thực tế.

Các bài kiểm thử end-to-end thường sẽ phát hiện các vấn đề với router của bạn, thư viện quản lý trạng thái, các thành phần cấp cao (ví dụ: một ứng dụng hoặc bố cục), tài sản công cộng, hoặc bất kỳ xử lý yêu cầu nào. Như đã nói ở trên, chúng phát hiện các vấn đề quan trọng có thể không thể phát hiện được bằng các bài kiểm thử đơn vị hoặc kiểm thử thành phần.

Các bài kiểm thử end-to-end không nhập bất kỳ mã nguồn của ứng dụng Vue của bạn mà thay vào đó hoàn toàn dựa vào việc kiểm thử ứng dụng của bạn bằng cách điều hướng qua các trang hoàn chỉnh trong một trình duyệt thực sự.

Các bài kiểm thử end-to-end xác nhận nhiều tầng trong ứng dụng của bạn. Chúng có thể nhắm mục tiêu vào ứng dụng được xây dựng cục bộ của bạn hoặc thậm chí là một môi trường Staging thực tế. Kiểm thử đối với môi trường Staging của bạn không chỉ bao gồm mã nguồn frontend và máy chủ tĩnh của bạn mà còn bao gồm tất cả các dịch vụ backend và cơ sở hạ tầng liên quan.

Càng nhiều bài kiểm thử giống như cách phần mềm của bạn được sử dụng, càng nhiều sự tự tin chúng có thể mang lại cho bạn. – Kent C. Dodds – Tác giả của Thư Viện Kiểm Thử

Bằng cách kiểm thử cách các hành động của người dùng ảnh hưởng đến ứng dụng của bạn, các bài kiểm thử E2E thường là chìa khóa cho sự tự tin cao hơn trong việc ứng dụng hoạt động đúng cách hay không.

7.1 Lựa Chọn Một Giải Pháp Kiểm Thử E2E

Mặc dù kiểm thử end-to-end (E2E) trên web đã nhận được danh tiếng tiêu cực về các bài kiểm thử không đáng tin cậy (flaky) và làm chậm quá trình phát triển, các công cụ E2E hiện đại đã tiến xa hơn để tạo ra các bài kiểm thử đáng tin cậy, tương tác và hữu ích hơn. Khi lựa chọn một framework kiểm thử E2E, các phần sau cung cấp một số hướng dẫn về những điều cần lưu ý khi lựa chọn framework kiểm thử cho ứng dụng của bạn.

Kiểm thử đa trình duyệt

Một trong những lợi ích chính mà kiểm thử end-to-end (E2E) được biết đến là khả năng kiểm thử ứng dụng của bạn trên nhiều trình duyệt. Mặc dù có vẻ muốn có 100% phạm vi kiểm thử đa trình duyệt, nhưng quan trọng là phải nhận biết rằng kiểm thử đa trình duyệt có hiệu suất giảm dần đối với tài nguyên của một nhóm do thời gian và sức mạnh máy tính bổ sung cần thiết để chạy chúng một cách nhất quán. Do đó, quan trọng là phải thận trọng khi lựa chọn mức độ kiểm thử đa trình duyệt mà ứng dụng của bạn cần.

Vòng lặp phản hồi nhanh hơn

Một trong những vấn đề chính với các bài kiểm thử end-to-end (E2E) và phát triển là việc chạy toàn bộ bộ kiểm thử mất rất nhiều thời gian. Thông thường, điều này chỉ được thực hiện trong các đường ống tích hợp và triển khai liên tục (CI/CD). Các framework kiểm thử E2E hiện đại đã giúp giải quyết vấn đề này bằng cách thêm các tính năng như song song hóa, cho phép các đường ống CI/CD thường chạy nhanh hơn đáng kể so với trước đây. Ngoài ra, khi phát triển cục bộ, khả năng chạy một bài kiểm thử đơn lẻ cho trang bạn đang làm việc trên đồng thời cung cấp tải lại nóng (hot reloading) của các bài kiểm thử có thể giúp tăng cường luồng làm việc và năng suất của một nhà phát triển.

Trải nghiệm gỡ lỗi hàng đầu

Trong khi các nhà phát triển truyền thống đã phụ thuộc vào quét logs trong cửa sổ terminal để giúp xác định điều gì đã sai trong một bài kiểm thử, các framework kiểm thử end-to-end (E2E) hiện đại cho phép các nhà phát triển tận dụng các công cụ mà họ đã quen thuộc, ví dụ như công cụ phát triển trình duyệt.

Tính hiển thị trong chế độ headless

Khi các bài kiểm thử end-to-end (E2E) được chạy trong các đường ống tích hợp/triển khai liên tục, chúng thường được chạy trong trình duyệt headless (tức là không có trình duyệt hiển thị nào được mở để người dùng xem). Một tính năng quan trọng của các framework kiểm thử E2E hiện đại là khả năng xem các bản chụp màn hình và/hoặc video của ứng dụng trong quá trình kiểm thử, cung cấp một số thông tin về lý do tại sao các lỗi xảy ra. Lịch sử cho thấy việc duy trì các tích hợp này thường gặp phải sự phiền toái.

7.2 Đề xuất

  • Cypress
    Tổng thể, chúng tôi tin rằng Cypress cung cấp giải pháp E2E hoàn chỉnh nhất với các tính năng như giao diện đồ họa đầy đủ thông tin, khả năng gỡ lỗi tốt, các khẳng định và các giả giọng tích hợp, chống flaky, song song hóa và các bản chụp màn hình. Như đã đề cập ở trên, nó cũng cung cấp hỗ trợ cho Kiểm thử Component. Tuy nhiên, nó chỉ hỗ trợ trình duyệt dựa trên Chromium và Firefox.

7.3 Các Lựa Chọn Khác

  • Playwright cũng là một giải pháp kiểm thử E2E tuyệt vời với một loạt hỗ trợ trình duyệt rộng hơn (chủ yếu là WebKit). Xem Tại sao sử dụng Playwright để biết thêm chi tiết.
  • Nightwatch là một giải pháp kiểm thử E2E dựa trên Selenium WebDriver. Điều này giúp nó có phạm vi hỗ trợ trình duyệt rộng nhất.
  • WebdriverIO là một framework tự động hóa kiểm thử cho kiểm thử web và di động dựa trên giao thức WebDriver.

8. Công thức

8.1 Thêm Vitest vào Dự án

Trong dự án Vue dựa trên Vite, chạy:

npm install -D vitest happy-dom @testing-library/vue

Tiếp theo, cập nhật cấu hình Vite để thêm khối tùy chọn test:


// vite.config.js
import { defineConfig } from 'vite'

export default defineConfig({
  // ...
  test: {
    // enable jest-like global test APIs
    globals: true,
    // simulate DOM with happy-dom
    // (requires installing happy-dom as a peer dependency)
    environment: 'happy-dom'
  }
})

tip Nếu bạn sử dụng TypeScript, thêm vitest/globals vào trường types trong tsconfig.json của bạn.


// tsconfig.json

{
  "compilerOptions": {
    "types": ["vitest/globals"]
  }
}

Sau đó, tạo một tệp kết thúc bằng *.test.js trong dự án của bạn. Bạn có thể đặt tất cả các tệp kiểm thử trong một thư mục kiểm thử trong thư mục gốc của dự án hoặc trong các thư mục kiểm thử kế bên các tệp nguồn của bạn. Vitest sẽ tự động tìm kiếm chúng bằng quy ước đặt tên.

// MyComponent.test.js
import { render } from '@testing-library/vue'
import MyComponent from './MyComponent.vue'

test('it should work', () => {
  const { getByText } = render(MyComponent, {
    props: {
      /* ... */
    }
  })

  // assert output
  getByText('...')
})

Cuối cùng, cập nhật package.json để thêm kịch bản kiểm thử và chạy nó:

on{4}
{
  // ...
  "scripts": {
    "test": "vitest"
  }
}
npm test

8.2 Kiểm thử Composables

Phần này giả định bạn đã đọc phần Composables.

Khi đến việc kiểm thử composables, chúng ta có thể chia thành hai loại: composables không phụ thuộc vào một phiên bản thành phần chủ, và composables có phụ thuộc.

Một composable phụ thuộc vào một phiên bản thành phần chủ khi nó sử dụng các API sau:

  • Lifecycle hooks
  • Provide / Inject

Nếu một composable chỉ sử dụng các API Phản ứng, thì nó có thể được kiểm tra bằng cách gọi trực tiếp và xác nhận trạng thái/phương thức được trả về của nó.

// counter.js
import { ref } from 'vue'

export function useCounter() {
  const count = ref(0)
  const increment = () => count.value++

  return {
    count,
    increment
  }
}
// counter.test.js
import { useCounter } from './counter.js'

test('useCounter', () => {
  const { count, increment } = useCounter()
  expect(count.value).toBe(0)

  increment()
  expect(count.value).toBe(1)
})

Một composable dựa vào các hooks vòng đời hoặc Provide / Inject cần được bọc trong một thành phần chủ để được kiểm tra. Chúng ta có thể tạo một trợ giúp như sau:

// test-utils.js
import { createApp } from 'vue'

export function withSetup(composable) {
  let result
  const app = createApp({
    setup() {
      result = composable()
      // suppress missing template warning
      return () => {}
    }
  })
  app.mount(document.createElement('div'))
  // return the result and the app instance
  // for testing provide/unmount
  return [result, app]
}
import { withSetup } from './test-utils'
import { useFoo } from './foo'

test('useFoo', () => {
  const [result, app] = withSetup(() => useFoo(123))
  // mock provide for testing injections
  app.provide(...)
  // run assertions
  expect(result.foo.value).toBe(1)
  // trigger onUnmounted hook if needed
  app.unmount()
})

Đối với các composables phức tạp hơn, cũng có thể dễ dàng kiểm thử bằng cách viết các bài kiểm thử đối với thành phần bọc sử dụng các kỹ thuật Kiểm thử Component.

Trên con đường phát triển ứng dụng Vuejs, việc tích hợp kiểm thử là một bước không thể thiếu. Tại Cafedev, chúng tôi hy vọng rằng thông qua hướng dẫn này, bạn đã có cái nhìn tổng quan về cách kiểm thử ứng dụng Vuejs một cách hiệu quả và chuyên nghiệp. Sự tự tin trong việc kiểm thử không chỉ giúp tăng cường chất lượng của sản phẩm mà còn là bước quan trọng trong việc xây dựng sự uy tín và niềm tin từ phía người dùng. Hãy cùng Cafedev tiến xa hơn trên con đường phát triển ứng dụng Vuejs của bạn!

Tham khảo thêm: MIỄN PHÍ 100% | Series tự học Vuejs từ cơ bản tới nâng cao

Các nguồn kiến thức MIỄN PHÍ VÔ GIÁ từ cafedev tại đây

Nếu bạn thấy hay và hữu ích, bạn có thể tham gia các kênh sau của CafeDev để nhận được nhiều hơn nữa:

Chào thân ái và quyết thắng!

Đăng ký kênh youtube để ủng hộ Cafedev nha các bạn, Thanks you!

BÀI VIẾT LIÊN QUANXEM THÊM