Đối với các thử nghiệm từ đầu đến cuối (E2E) ổn định, chúng tôi cần một môi trường cách ly với bên ngoài nhất có thể.  giảm bong tróc  Các bài kiểm tra không ổn định là các bài kiểm tra không thành công vì những lý do không liên quan đến mã của bạn. Chúng gây khó khăn cho việc sử dụng E2E như một biện pháp kiểm tra đáng tin cậy về tính chính xác của ứng dụng. Trong những trường hợp cực đoan, các bài kiểm tra không ổn định sẽ dạy cho nhóm của bạn bỏ qua kết quả E2E. Điều này có thể giết chết nỗ lực tự động hóa kiểm soát chất lượng (QA).  Cách tiếp cận được trình bày ở đây giải quyết hai nguồn vấn đề tiềm ẩn lớn trong quá trình chạy thử nghiệm của bạn:  Trạng thái được lưu trữ bởi chương trình phụ trợ được chia sẻ bởi các công việc kiểm tra khác nhau và  Các dịch vụ bên ngoài mà bạn không kiểm soát được.  Có những nguồn bong tróc khác không bị ảnh hưởng bởi phương pháp này:  Vấn đề thực sự là trong ứng dụng xuất hiện ngẫu nhiên hoặc  Các sự cố trong ứng dụng là do tốc độ không tự nhiên mà E2E tương tác với nó gây ra.  Thay thế  Trước khi tôi và nhóm của mình chạy thử nghiệm với một bộ chứa phụ trợ chuyên dụng, chúng tôi đã sử dụng một trong những máy chủ không sản xuất của mình. Cách tiếp cận này phù hợp ở giai đoạn thử nghiệm giải pháp E2E của chúng tôi.  Khi chỉ có một vài bài kiểm tra, chúng tôi không thể sử dụng kết quả bài kiểm tra để đưa ra quyết định.  Tuy nhiên, khi chúng tôi tiếp tục thêm nhiều thử nghiệm hơn và tạo ra thời gian thực hiện lâu hơn, phương pháp này bắt đầu thất bại. Các vấn đề chính như sau:  Mặc dù chúng tôi đã cố gắng hoàn nguyên các thay đổi dữ liệu bên trong thử nghiệm, nhưng một số lỗi thử nghiệm đã để lại những thay đổi không mong muốn.  Các công việc song song đã xung đột. Các công việc thử nghiệm khác nhau đang thay đổi cùng một trạng thái, điều này thường khiến một trong các công việc bị lỗi.  Docker hóa mọi thứ  Một giải pháp cho vấn đề này là dành riêng một máy chủ phụ trợ và cơ sở dữ liệu cho từng công việc kiểm tra. Cách tiếp cận này sẽ rất khó khăn nếu không có Docker.  Bộ chứa Docker là một công cụ hoàn hảo để tạo một môi trường chứa mọi thứ mà một ứng dụng cần để chạy:  Hệ điều hành phù hợp (hay đúng hơn là bản phân phối Linux phù hợp),  các phụ thuộc hệ thống, chẳng hạn như thư viện thao tác hình ảnh, v.v., và  Phiên bản chính xác của trình thông dịch ngôn ngữ (Python, Node, v.v.) hoặc máy chủ cơ sở dữ liệu.  cơ sở dữ liệu  Đối với thử nghiệm của mình, bạn có thể chuẩn bị một bộ chứa cơ sở dữ liệu chuyên dụng đi kèm với dữ liệu thử nghiệm có thể dự đoán được. Bằng cách này, bạn sẽ có thể tái tạo chính xác điểm bắt đầu trong mỗi lần thực thi E2E—làm cho các thử nghiệm của bạn ổn định hơn.  Bạn có thể sử dụng các thẻ khác nhau cho hình ảnh Docker của mình để tạo phiên bản cho cơ sở dữ liệu thử nghiệm. Cơ sở dữ liệu thử nghiệm tương tự cũng có thể được sử dụng trong môi trường phát triển. Đối với các thử nghiệm thủ công trong quá trình phát triển, bạn cần các thực thể ví dụ tương tự như đối với các thử nghiệm tự động.  phụ trợ  Nếu bạn đã sử dụng Docker để triển khai chương trình phụ trợ của mình, sẽ khá dễ dàng để sử dụng lại cùng một hình ảnh để chạy E2E của bạn. Trong nhóm của tôi, chúng tôi triển khai một chương trình phụ trợ dưới dạng vùng chứa và chúng tôi cung cấp URL cơ sở dữ liệu cũng như thông tin xác thực dưới dạng biến môi trường.  Phiên bản vùng chứa giống hệt nhau có thể được triển khai trong sản xuất hoặc được sử dụng trong tích hợp liên tục (CI) để chạy thử nghiệm—mỗi môi trường cung cấp các giá trị phù hợp để kết nối với DB.  giao diện người dùng  Tùy thuộc vào chiến lược triển khai của bạn, bạn có thể thực hiện một trong các thao tác sau:  Sử dụng các thùng chứa bạn xây dựng như một phần của bản dựng giao diện người dùng.  Nhận các tệp đã biên dịch và đảm bảo rằng chúng có sẵn qua HTTP để kiểm tra.  Trong trường hợp của chúng tôi, chúng tôi sử dụng tùy chọn 2: chúng tôi triển khai ứng dụng dưới dạng tệp tĩnh, vì vậy chúng tôi chỉ tạo một vùng chứa chuyên dụng để phục vụ các tệp đã tạo trong quá trình chạy công việc E2E.  Dịch vụ việc làm trong GitLab  Chúng tôi sử dụng GitLab làm nền tảng để chạy CI của mình. Mỗi công việc trong GitLab được chạy bên trong một thùng chứa có hình ảnh bạn chọn. Bên cạnh vùng chứa chính, bạn có thể xác định   : Các vùng chứa bổ sung chạy cùng với các thử nghiệm của bạn. Cấu hình dễ dàng như: các dịch vụ   <job-name>: services: - name: <image> alias: <container-url>  Các tùy chọn có sẵn tương tự như những gì bạn có trong Docker Compose, nhưng chúng bị hạn chế hơn.  Một "điều cần biết" trong cấu hình GitLab là đặt biến   thành 1 nếu bạn muốn cho phép các dịch vụ truy cập lẫn nhau trong quá trình chạy thử nghiệm. FF_NETWORK_PER_BUILD  Xem xét dữ liệu đặc biệt cho sự cô lập trong công việc  Tại một số thời điểm, chúng tôi đang chạy song song tất cả các bài kiểm tra trong một công việc. Vào thời điểm đó, cần phải thực thi cách ly mạnh mẽ hơn nữa—mỗi bài kiểm tra đều sử dụng cùng một cơ sở dữ liệu và phụ trợ.  Để khắc phục sự cố này, chúng tôi đã nâng cấp các thử nghiệm của mình để phụ thuộc chủ yếu vào dữ liệu ngẫu nhiên mà chúng tôi đưa vào ngay bên trong phần   của thử nghiệm. Điều này cho phép các bài kiểm tra chạy mà không bị ảnh hưởng bởi những thay đổi khác xảy ra trong các luồng khác. before  Cách tiếp cận này ban đầu có thể hơi phức tạp, nhưng nó có ý nghĩa tùy thuộc vào hoàn cảnh của bạn.  Dọn dẹp sau mỗi lần kiểm tra  Mặc dù chúng tôi bắt đầu một cơ sở dữ liệu mới cho từng công việc kiểm thử, nhưng chúng tôi vẫn đang cố gắng làm cho các kiểm thử của mình rời khỏi ứng dụng ở trạng thái giống như khi họ tìm thấy nó. Có lẽ đó là một chút gì đó còn sót lại từ thời kỳ chúng tôi chạy thử nghiệm trong môi trường dùng chung.  Nó không còn quan trọng nữa, nhưng nó vẫn có thể giúp ích trong quá trình phát triển thử nghiệm trong các trường hợp sau:  Khi bạn chỉ chạy một bài kiểm tra—do đó, trạng thái mà bài kiểm tra gặp phải không khác với khi bạn chạy tất cả các bài kiểm tra trong tệp.  Khi bạn chạy đi chạy lại cùng một bài kiểm tra cục bộ—để cơ sở dữ liệu không bị ảnh hưởng bởi các lần chạy trước đó  Mô phỏng dịch vụ bên ngoài  Có những trường hợp khi chuyển dịch vụ sang vùng chứa không phải là một tùy chọn. Ví dụ:  Nếu có các máy chủ bên ngoài mà ứng dụng sử dụng trực tiếp hoặc thông qua một số proxy phụ trợ, hoặc  Bạn sở hữu các máy chủ không thể chạy bên trong vùng chứa do sự cố kỹ thuật.  Trong cả hai trường hợp, để tách biệt các lần chạy thử nghiệm, bạn có thể mô phỏng các yêu cầu chuyển đến các dịch vụ đó. Điều này sẽ ngăn các dịch vụ bên ngoài không thể đoán trước ảnh hưởng đến kết quả kiểm tra của bạn. Nhược điểm của phương pháp này là các thử nghiệm của bạn sẽ ngắt kết nối với ngữ cảnh mà ứng dụng của bạn hoạt động.  Với các bản mô phỏng tại chỗ, các bài kiểm tra của bạn sẽ   phát hiện ra các trường hợp khi các thay đổi trong các dịch vụ đó ảnh hưởng đến ứng dụng của bạn. không  Tiếp tục học  Nếu bạn muốn tìm hiểu thêm về thử nghiệm hoặc các chủ đề khác liên quan đến lập trình, bạn có thể đăng ký   để nhận thông tin cập nhật khi tôi xuất bản nội dung liên quan. tại đây

2022 - HackerNoon Contributor of the Year - Beginners Guide

2022 - HackerNoon Contributor of the Year - Code Quality

2022 - HackerNoon Contributor of the Year - Learning

2022 - the Greatest Storyteller

Newsletter

Senior JS developer

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

Thiết lập môi trường từ đầu đến cuối được cách ly hoàn hảo

About Author

BÌNH LUẬN

chuyên mục

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI

Related Stories

94 Stories To Learn About John Locke

128 Stories To Learn About Charles Dickens

309 Stories To Learn About Smart Contracts

189 Stories To Learn About Reading Books

94 Stories To Learn About John Locke

128 Stories To Learn About Charles Dickens

309 Stories To Learn About Smart Contracts

189 Stories To Learn About Reading Books

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps