Xin chào tất cả mọi người!

Tôi đã được truyền cảm hứng để viết bài báo này bởi các sinh viên và người được cố vấn của tôi. Tôi thường khuyên họ nên học TypeScript ngay khi họ cảm thấy thoải mái với quy trình tự động hóa thử nghiệm trên JavaScript . Hãy xem những đặc điểm của việc sử dụng TypeScript trong khung tự động hóa thử nghiệm của bạn về mặt thử nghiệm API REST là gì…

Bạn có thể tìm thấy mã đầy đủ của dự án thử nghiệm tại đây .

bản đánh máy

Chúng ta đừng đi quá sâu vào TypeScript là gì và nó khác với JavaScript như thế nào và nêu rõ điều quan trọng - đó là ngôn ngữ lập trình . Nhưng, cũng khá quan trọng - nó phụ thuộc trực tiếp vào JavaScript (nền tảng Node.js ).

TypeScript được trình bày dưới dạng gói Node.js , vì vậy tôi xem nó giống như JavaScript với một số tính năng thú vị.

Để tìm hiểu thêm về chính ngôn ngữ này và những gì nó cung cấp - vui lòng truy cập trang web chính thức trong khi chúng tôi sẽ nói về các tính năng của nó về tự động hóa thử nghiệm…

Thiết lập dự án

Hãy xem qua quy trình tạo dự án tự động hóa thử nghiệm trên TypeScript :

1. Tạo một dự án Node.js.

   npm init -y

2. Cài đặt gói TypeScript .

   npm i typescript

3. Tạo cấu hình TypeScript mặc định cho dự án - tsconfig.json .

   npx tsc --init

Lệnh trên sẽ tạo một tệp cấu hình mặc định, nhưng tôi khuyên bạn nên rút ngắn nó thành một tệp như sau :

 { "compilerOptions": { "baseUrl": "./", "module": "esnext", "target": "esnext", "sourceMap": false, "moduleResolution": "node", "allowJs": true, "skipLibCheck": true, "resolveJsonModule": true, "allowSyntheticDefaultImports": true, "paths": { "*": ["./*"] } } }

Cấu hình này chứa mức tối thiểu bắt buộc:

• sử dụng phiên bản EcmaScript mới nhất,
• cung cấp các bản nhập JSON,
• cho phép bạn sử dụng đường dẫn tuyệt đối trong nhập khẩu.

Bạn có thể mở rộng cấu hình của mình bằng tài liệu chính thức .

Lựa chọn công cụ

Bạn có thể sử dụng bất kỳ công cụ nào mà hệ sinh thái Node.js cung cấp, nhưng theo kinh nghiệm của tôi - hầu hết các kỹ sư làm việc với TypeScript đều chọn Jest vì một số lý do chính đáng:

• hỗ trợ cộng đồng tuyệt vời (cập nhật, câu trả lời, tài liệu, mã ví dụ),
• cấu hình linh hoạt.

Trước đây, tôi rất vui khi sử dụng Mocha + Chai để thiết lập cốt lõi của dự án, nhưng bây giờ tôi cũng gắn bó với Jest , vì nó chứa cả thư viện xác nhận và người chạy thử nghiệm.

Axios dường như là ứng dụng khách HTTP phổ biến nhất, vì vậy tôi khuyên bạn cũng nên chọn đây.

Không thể nói rằng bạn buộc phải sử dụng điều này cho thiết lập của mình, nhưng tôi đang nói rằng đó là điều bình thường khi bạn xem qua các dự án.

Bây giờ, chỉ cần cài đặt các gói này dưới dạng phụ thuộc:

npm i jest axios

Loại bộ sưu tập

Một số gói (như Axios ) chứa các loại TypeScript bên trong, nhưng Jest & Mocha thì không. Ngoài ra, Jest yêu cầu gói ts-jest cùng với @types/jest để hoạt động bình thường - gói đầu tiên kích hoạt các tính năng của TypeScript và gói thứ hai cho phép bạn sử dụng IntelliSense .

Vì vậy, hãy ghi nhớ - nếu bạn không có tính năng tự động hoàn thành khi bạn đang cố gắng sử dụng một số gói - thì có thể bạn đang thiếu các khai báo kiểu.

Hãy cài đặt cả các phần mở rộng (gói) liên quan đến TypeScript :

npm i ts-jest @types/jest

Cấu hình

Jest yêu cầu cài đặt trước cấu hình ts-jest , vì vậy bạn phải khai báo nó trong tệp cấu hình (hoặc package.json ):

 { "jest": { "preset": "ts-jest" } }

Nếu bạn dự định sử dụng đường dẫn tuyệt đối trong một dự án , bạn cũng cần điều chỉnh cấu hình của mình:

 { "jest": { "preset": "ts-jest", "moduleDirectories": [ "node_modules", "<rootDir>" ] } }

Cấu hình này cho phép bạn chạy thử nghiệm bằng một lệnh đơn giản... jest

Vì vậy, hãy định cấu hình tập lệnh thử nghiệm của bạn trong pack.json thành:

 { "scripts": { "test": "jest" } }

Và sau đó chạy thử nghiệm của bạn bất cứ lúc nào với lệnh npm test hoặc npm run test .

Tôi cũng khuyên bạn nên cài đặt tiện ích mở rộng Jest Runner nếu bạn là người dùng Visual Studio Code - tiện ích này cho phép bạn chạy / gỡ lỗi các thử nghiệm/bộ phần mềm mong muốn chỉ bằng một cú nhấp chuột. Trong WebStorm, đó là một tính năng tích hợp sẵn.

các loại tùy chỉnh

Tính năng chính mà TypeScript đưa vào thử nghiệm API REST là... các loại , tất nhiên rồi!

Bạn có thể khai báo nội dung yêu cầu và phản hồi của bạn sẽ như thế nào, tức là, tên chính , loại giá trị và vân vân.

Hãy lấy một máy chủ Paysis làm ví dụ - chúng ta có thể ghi tải trọng nội dung yêu cầu của nó cho điểm cuối /auth dưới dạng một loại:

 export type AuthRequestBody = { login: string password: string }

Và tương tự đối với nội dung phản hồi - máy chủ nào sẽ gửi yêu cầu của chúng tôi:

 export type AuthResponseBody = { token?: string message?: string }

Vì sẽ có một tải trọng khác cho các tình huống thành công/thất bại - bạn có thể đánh dấu các khóa là "tùy chọn" thông qua nút “ ?” tính cách.

Sau khi hoàn tất - bạn có thể sử dụng các loại này để soạn yêu cầu và xác minh trong các thử nghiệm của mình...

Lời yêu cầu

Trong Axios , bạn có thể nói nội dung bạn đang gửi thông qua cấu hình yêu cầu:

 const payload: AxiosRequestConfig<AuthRequestBody> = { method: 'post', url: '/auth', data: { login: process.env.USERNAME, password: process.env.PASSWORD, }, }

AuthRequestBody trong AxiosRequestConfig<AuthRequestBody> chính xác có nghĩa như vậy ☝️

Điều đó có nghĩa là bạn sẽ buộc phải sử dụng tải trọng phù hợp với loại được cung cấp AuthRequestBody trong đối tượng data . Nếu bạn quên đặt một số trường bắt buộc hoặc đặt một số trường quá mức - bạn sẽ thấy lỗi.

Phản ứng

Điều tương tự cũng có thể được thực hiện về phản hồi:

 const response: AxiosResponse<AuthResponseBody> = await client.request(payload)

Nó sẽ thêm tính năng tự động điền vào đối tượng response.data , vì vậy, bạn có thể tiếp cận các trường response.data.token hoặc response.data.message .

Công cụ nâng cao

Ngoài những nội dung đơn giản ở trên, bạn cũng có thể tạo lược đồ JSON từ các loại tùy chỉnh của mình . Nó cho phép bạn không kiểm tra từng khóa đơn lẻ trong nội dung phản hồi để xem liệu nó có khớp với lược đồ hay không mà kiểm tra toàn bộ tải trọng .

Vì vậy, ý tưởng là:

1. Tạo lược đồ JSON từ các loại tùy chỉnh.
2. Sử dụng công cụ so khớp tùy chỉnh toMatchSchema để xác thực nội dung phản hồi.

Nội dung khá thú vị, nhưng hãy nhớ rằng các thử nghiệm của bạn có thể trở nên không ổn định sau những thay đổi này - điều này xảy ra khi một số trường bổ sung xuất hiện, vì vậy bạn cần cập nhật giản đồ thường xuyên.

Phần kết luận

Thiết lập TypeScript có thể phức tạp, đặc biệt nếu đây là lần đầu tiên của bạn, nhưng nó đáng giá!

Nếu bạn bao gồm dữ liệu đầu vào và đầu ra của mình bằng các loại - không có cách nào bạn mắc lỗi đánh máy hoặc một số lỗi cú pháp khác khi bạn phân tích cú pháp các đối tượng này. Nó giúp bạn tránh khỏi những lỗi đơn giản và cho phép bạn xem cấu trúc của các yêu cầu ngay trong mã của mình, vì vậy bạn không phải mở bất kỳ bộ sưu tập HTTP nào (như Postman ) và tìm kiếm yêu cầu bạn cần để xem nội dung yêu cầu/phản hồi với.

Hãy cho tôi biết về kinh nghiệm của bạn và những gì bạn nghĩ về nó.