Chúng ta đều biết rằng chúng ta nên viết các bài kiểm tra đơn vị. Tuy nhiên, thật khó để biết bắt đầu từ đâu và dành bao nhiêu thời gian cho các bài kiểm tra so với việc triển khai thực tế. Vì vậy, bắt đầu từ đâu? Và đó chỉ là kiểm tra mã hay kiểm tra đơn vị có những lợi ích khác?
Trong bài viết này, tôi sẽ giải thích các loại thử nghiệm khác nhau và những lợi ích mà thử nghiệm đơn vị mang lại cho các nhóm phát triển. Tôi sẽ giới thiệu Jest – một khung kiểm tra JavaScript.
Các loại thử nghiệm khác nhau
Trước khi chúng tôi đi sâu vào các chi tiết cụ thể của thử nghiệm đơn vị, tôi muốn thực hiện nhanh các loại thử nghiệm khác nhau. Thường có một số nhầm lẫn xung quanh chúng và tôi không ngạc nhiên. Đôi khi ranh giới giữa chúng khá mong manh.
bài kiểm tra đơn vị
Các bài kiểm tra đơn vị chỉ kiểm tra một phần trong quá trình triển khai của bạn. Một đơn vị. Không phụ thuộc hoặc tích hợp, không có chi tiết cụ thể về khung. Chúng giống như một phương thức trả về một liên kết bằng một ngôn ngữ cụ thể:
export function getAboutUsLink(language){
switch (language.toLowerCase()){
case englishCode.toLowerCase():
return '/about-us';
case spanishCode.toLowerCase():
return '/acerca-de';
}
return '';
}kiểm tra tích hợp
Tại một số điểm, mã của bạn giao tiếp với cơ sở dữ liệu, hệ thống tệp hoặc bên thứ ba khác. Nó thậm chí có thể là một mô-đun khác trong ứng dụng của bạn.
Phần triển khai đó phải được kiểm tra bằng các bài kiểm tra tích hợp. Chúng thường có một thiết lập phức tạp hơn liên quan đến việc chuẩn bị môi trường thử nghiệm, khởi tạo các phụ thuộc, v.v.
kiểm tra chức năng
Kiểm tra đơn vị và kiểm tra tích hợp giúp bạn tự tin rằng ứng dụng của mình hoạt động. Kiểm tra chức năng xem xét ứng dụng từ quan điểm của người dùng và kiểm tra xem hệ thống có hoạt động như mong đợi hay không.
Trong sơ đồ trên, bạn thấy rằng các bài kiểm tra đơn vị tạo thành cơ sở lớn cho bộ kiểm tra ứng dụng của bạn. Thông thường, chúng nhỏ, có rất nhiều trong số chúng và chúng được thực thi tự động.
Vì vậy, bây giờ chúng ta hãy đi vào các bài kiểm tra đơn vị chi tiết hơn một chút.
Tại sao tôi nên bận tâm viết bài kiểm tra đơn vị?
Bất cứ khi nào tôi hỏi các nhà phát triển liệu họ có viết bài kiểm tra cho ứng dụng của họ hay không, họ luôn nói với tôi: “Tôi không có thời gian cho chúng” hoặc “Tôi không cần chúng, tôi biết nó hoạt động.”
Vì vậy, tôi mỉm cười lịch sự và nói với họ những gì tôi muốn nói với bạn. Kiểm tra đơn vị không chỉ là kiểm tra. Họ cũng giúp bạn theo những cách khác, vì vậy bạn có thể:
Hãy tự tin rằng mã của bạn hoạt động. Lần cuối cùng bạn cam kết thay đổi mã, bản dựng của bạn không thành công và một nửa ứng dụng của bạn ngừng hoạt động là khi nào? Của tôi là tuần trước.
Nhưng điều đó vẫn ổn. Vấn đề thực sự là khi quá trình xây dựng thành công, thay đổi được triển khai và ứng dụng của bạn bắt đầu không ổn định.
Khi điều đó xảy ra, bạn bắt đầu mất niềm tin vào mã của mình và cuối cùng chỉ biết cầu nguyện cho ứng dụng hoạt động. Các bài kiểm tra đơn vị sẽ giúp bạn phát hiện ra các vấn đề sớm hơn nhiều và có được sự tự tin.
Đưa ra quyết định kiến trúc tốt hơn. Mã thay đổi, nhưng một số quyết định về nền tảng, mô-đun, cấu trúc và các quyết định khác cần được đưa ra trong giai đoạn đầu của dự án.
Khi bạn bắt đầu nghĩ về thử nghiệm đơn vị ngay từ đầu, nó sẽ giúp bạn cấu trúc mã của mình tốt hơn và đạt được sự phân tách hợp lý các mối quan tâm. Bạn sẽ không muốn gán nhiều trách nhiệm cho các khối mã đơn lẻ vì đó sẽ là cơn ác mộng đối với kiểm thử đơn vị.
Xác định chức năng trước khi viết mã. Bạn viết chữ ký của phương thức và bắt đầu thực hiện nó ngay lập tức. Ồ, nhưng điều gì sẽ xảy ra trong trường hợp một tham số là null? Nếu giá trị của nó nằm ngoài phạm vi dự kiến hoặc chứa quá nhiều ký tự thì sao? Bạn có ném ngoại lệ hoặc trả về giá trị rỗng không?
Unit test sẽ giúp bạn khám phá tất cả những trường hợp này. Hãy xem lại các câu hỏi và bạn sẽ thấy đó chính xác là điều xác định các trường hợp kiểm thử đơn vị của bạn.
Tôi chắc chắn rằng có nhiều lợi ích hơn khi viết bài kiểm tra đơn vị. Đây chỉ là những điều mà tôi nhớ lại từ kinh nghiệm của mình. Những điều mà tôi đã học được một cách khó khăn.
Cách viết bài kiểm tra đơn vị JavaScript đầu tiên của bạn
Nhưng hãy quay lại với JavaScript. Chúng ta sẽ bắt đầu với Jest, đây là một khung kiểm tra JavaScript. Đó là một công cụ cho phép kiểm tra đơn vị tự động, cung cấp phạm vi mã và cho phép chúng tôi dễ dàng mô phỏng các đối tượng. Jest cũng có tiện ích mở rộng cho Visual Studio Code tại đây.
Ngoài ra còn có các framework khác, nếu bạn quan tâm có thể tham khảo tại bài viết này.
npm i jest --save-dev
Hãy sử dụng phương pháp đã đề cập trước đó getAboutUsLink như một triển khai, chúng tôi muốn thử nghiệm:
const englishCode = "en-US";
const spanishCode = "es-ES";
function getAboutUsLink(language){
switch (language.toLowerCase()){
case englishCode.toLowerCase():
return '/about-us';
case spanishCode.toLowerCase():
return '/acerca-de';
}
return '';
}
module.exports = getAboutUsLink;
tôi đưa cái này vào index.js tập tin. Chúng ta có thể viết các bài kiểm tra trong cùng một tệp, nhưng một phương pháp hay là tách các bài kiểm tra đơn vị thành một tệp chuyên dụng.
Các mẫu đặt tên phổ biến bao gồm {filename}.test.js và {filename}.spec.js. Tôi đã sử dụng cái đầu tiên, index.test.js:
const getAboutUsLink = require("./index");
test("Returns about-us for english language", () => {
expect(getAboutUsLink("en-US")).toBe("/about-us");
});
Trước tiên, chúng ta cần nhập chức năng mà chúng ta muốn kiểm tra. Mỗi bài kiểm tra được định nghĩa là một lời gọi của test chức năng. Tham số đầu tiên là tên của bài kiểm tra để bạn tham khảo. Cái còn lại là một hàm mũi tên nơi chúng ta gọi hàm mà chúng ta muốn kiểm tra và chỉ định kết quả mà chúng ta mong đợi. Tôi
n trường hợp này, chúng tôi gọi getAboutUsLink chức năng với en-US làm tham số ngôn ngữ. Chúng tôi mong đợi kết quả là /about-us.
Bây giờ chúng ta có thể cài đặt Jest CLI trên toàn cầu và chạy thử nghiệm:
npm i jest-cli -g
jest
Nếu bạn thấy lỗi liên quan đến cấu hình, hãy đảm bảo bạn có package.json tập tin hiện tại. Trong trường hợp bạn không, hãy tạo một cái bằng cách sử dụng npm init.
Bạn sẽ thấy một cái gì đó như thế này:
PASS ./index.test.js
√ Returns about-us for english language (4ms)
console.log index.js:15
/about-us
Test Suites: 1 passed, 1 total
Tests: 1 passed, 1 total
Snapshots: 0 total
Time: 2.389s
Bạn đã làm rất tốt! Đây là bài kiểm tra đơn vị JavaScript đơn giản đầu tiên từ đầu đến cuối. Nếu bạn đã cài đặt tiện ích mở rộng Visual Studio Code, nó sẽ tự động chạy thử nghiệm sau khi bạn lưu tệp. Hãy thử bằng cách mở rộng bài kiểm tra với dòng này:
expect(getAboutUsLink("cs-CZ")).toBe("/o-nas");
Khi bạn lưu tệp, Jest sẽ thông báo cho bạn rằng thử nghiệm không thành công. Điều đó giúp bạn khám phá các vấn đề tiềm ẩn ngay cả trước khi thực hiện các thay đổi của mình.
Kiểm tra chức năng nâng cao và dịch vụ mô phỏng
Trong thực tế, mã ngôn ngữ cho phương thức getAboutUsLink sẽ không phải là hằng số trong cùng một tệp. Giá trị của chúng thường được sử dụng trong suốt dự án, vì vậy chúng sẽ được xác định trong mô-đun của riêng chúng và được nhập vào tất cả các chức năng sử dụng chúng.
import { englishCode, spanishCode } from './LanguageCodes'
Bạn có thể nhập các hằng số này vào bài kiểm tra theo cách tương tự. Nhưng tình hình sẽ trở nên phức tạp hơn nếu bạn đang làm việc với các đối tượng thay vì các hằng số đơn giản. Hãy xem phương pháp này:
import { UserStore } from './UserStore'
function getUserDisplayName(){
const user = UserStore.getUser(userId);
return `${user.LastName}, ${user.FirstName}`;
}
Phương pháp này sử dụng nhập khẩu UserStore:
class User {
getUser(userId){
// logic to get data from a database
}
setUser(user){
// logic to store data in a database
}
}
let UserStore = new User();
export { UserStore }
Để kiểm tra đơn vị đúng phương pháp này, chúng ta cần thử UserStore. Một giả là một thay thế cho đối tượng ban đầu. Nó cho phép chúng tôi tách biệt các phần phụ thuộc và dữ liệu thực khỏi quá trình triển khai của phương pháp đã thử nghiệm giống như hình nộm giúp thử nghiệm va chạm ô tô thay vì người thật.
Nếu chúng tôi không sử dụng bản mô phỏng, chúng tôi sẽ thử nghiệm cả chức năng này và cửa hàng. Đó sẽ là một thử nghiệm tích hợp và chúng tôi có thể sẽ cần phải mô phỏng cơ sở dữ liệu đã sử dụng.
Chế giễu một dịch vụ
Để mô phỏng các đối tượng, bạn có thể cung cấp chức năng mô phỏng hoặc mô phỏng thủ công. Tôi sẽ tập trung vào cái sau vì tôi có một trường hợp sử dụng đơn giản và đơn giản. Nhưng hãy thoải mái kiểm tra các khả năng mô phỏng khác mà Jest cung cấp.
jest.mock('./UserStore', () => ({
UserStore: ({
getUser: jest.fn().mockImplementation(arg => ({
FirstName: 'Ondrej',
LastName: 'Polesny'
})),
setUser: jest.fn()
})
}));
Trước tiên, chúng ta cần chỉ định những gì chúng ta đang chế nhạo – ./UserStore mô-đun. Tiếp theo, chúng ta cần trả về mô hình chứa tất cả các đối tượng đã xuất từ mô-đun đó.
Trong mẫu này, nó chỉ là User đối tượng được đặt tên UserStore với chức năng getUser. Nhưng với việc triển khai thực tế, giả định có thể lâu hơn nhiều. Bất kỳ chức năng nào bạn không thực sự quan tâm trong phạm vi thử nghiệm đơn vị đều có thể dễ dàng bị giả lập bằng jest.fn().
Bài kiểm tra đơn vị cho getUserDisplayName chức năng tương tự như chức năng chúng tôi đã tạo trước đây:
test("Returns display name", () => {
expect(getUserDisplayName(1)).toBe("Polesny, Ondrej");
})
Ngay sau khi tôi lưu tệp, Jest nói với tôi rằng tôi có 2 bài kiểm tra vượt qua. Nếu bạn đang thực hiện kiểm tra theo cách thủ công, hãy thực hiện ngay bây giờ và đảm bảo rằng bạn sẽ thấy kết quả tương tự.
Báo cáo bảo hiểm mã
Bây giờ chúng ta đã biết cách kiểm tra mã JavaScript, thật tốt khi kiểm tra càng nhiều mã càng tốt. Và điều đó thật khó thực hiện. Cuối cùng, chúng ta chỉ là con người. Chúng tôi muốn hoàn thành nhiệm vụ của mình và các bài kiểm tra đơn vị thường mang lại khối lượng công việc không mong muốn mà chúng tôi có xu hướng bỏ qua. Bảo hiểm mã là một công cụ giúp chúng tôi chống lại điều đó.
Phạm vi mã sẽ cho bạn biết phần mã của bạn được bao phủ bởi các bài kiểm tra đơn vị lớn như thế nào. Lấy ví dụ bài kiểm tra đơn vị đầu tiên của tôi kiểm tra getAboutUsLink chức năng:
test("Returns about-us for english language", () => {
expect(getAboutUsLink("en-US")).toBe("/about-us");
});
Nó kiểm tra liên kết tiếng Anh, nhưng phiên bản tiếng Tây Ban Nha vẫn chưa được kiểm tra. Độ bao phủ của mã là 50%. Bài kiểm tra đơn vị khác đang kiểm tra getDisplayName hoạt động triệt để và phạm vi bảo hiểm mã của nó là 100%. Cùng với nhau, tổng mức độ bao phủ của mã là 67%. Chúng tôi có 3 trường hợp sử dụng để thử nghiệm, nhưng thử nghiệm của chúng tôi chỉ bao gồm 2 trường hợp trong số đó.
Để xem báo cáo phạm vi mã, hãy nhập lệnh sau vào thiết bị đầu cuối:
jest --coverage
Hoặc, nếu bạn đang sử dụng Visual Studio Code với tiện ích mở rộng Jest, bạn có thể chạy lệnh (CTRL+SHIFT+P) Jest: Chuyển đổi lớp phủ bảo hiểm. Nó sẽ cho bạn thấy ngay trong quá trình triển khai những dòng mã nào không được kiểm tra.
Bằng cách chạy kiểm tra mức độ phù hợp, Jest cũng sẽ tạo một báo cáo HTML. Tìm nó trong thư mục dự án của bạn dưới coverage/lcov-report/index.html.
Bây giờ, tôi không cần phải đề cập rằng bạn nên cố gắng đạt được phạm vi bảo hiểm mã 100%, phải không? 🙂
Tóm lược
Trong bài viết này, tôi đã chỉ cho bạn cách bắt đầu với thử nghiệm đơn vị trong JavaScript. Mặc dù thật tuyệt khi phạm vi bảo hiểm mã của bạn tỏa sáng ở mức 100% trong báo cáo, nhưng trên thực tế, không phải lúc nào bạn cũng có thể đạt được điều đó (một cách có ý nghĩa). Mục tiêu là để các bài kiểm tra đơn vị giúp bạn duy trì mã của mình và đảm bảo mã luôn hoạt động như dự kiến. Chúng cho phép bạn:
- xác định rõ yêu cầu thực hiện,
- thiết kế tốt hơn mã của bạn và các mối quan tâm riêng biệt,
- khám phá các vấn đề bạn có thể gây ra với các cam kết mới hơn của mình,
- và cung cấp cho bạn sự tự tin rằng mã của bạn hoạt động.
Nơi tốt nhất để bắt đầu là trang Bắt đầu trong tài liệu về Jest để bạn có thể tự mình thử các phương pháp này.
Bạn có kinh nghiệm của riêng mình với mã thử nghiệm không? Tôi rất thích nghe nó, cho tôi biết trên Twitter hoặc tham gia một trong các luồng Twitch của tôi.
