Chào mừng! Rất vui được gặp bạn trong phần thứ sáu của loạt bài tóm tắt về Hội nghị Vuejs Amsterdam 2022 của tôi, trong đó tôi chia sẻ tóm tắt về tất cả các cuộc nói chuyện với bạn.

Bạn có thể đọc loạt bài Tóm tắt về Hội nghị JSWorld 2022 của tôi (gồm bốn phần) tại đây , nơi tôi đã tóm tắt tất cả các bài nói chuyện của ngày đầu tiên. Bạn cũng có thể tìm thấy các Bài nói trước của hội nghị Vue Amsterdam 2022 trong blog của tôi.

(Định kỳ) Giới thiệu

Sau hai năm rưỡi, Hội nghị JSWorld và Vue Amsterdam đã trở lại Nhà hát Amsterdam từ ngày 1 đến ngày 3 tháng 6, và tôi đã có cơ hội tham dự hội nghị này lần đầu tiên. Tôi đã học được nhiều điều, gặp nhiều người tuyệt vời, nói chuyện với những nhà phát triển tuyệt vời và đã có một khoảng thời gian tuyệt vời. Vào ngày đầu tiên, Hội nghị JSWorld được tổ chức, và vào ngày thứ hai và thứ ba, Vue Amsterdam.

Hội nghị có đầy đủ thông tin với các diễn giả tuyệt vời, mỗi người trong số họ đã dạy cho tôi điều gì đó có giá trị. Tất cả họ đều muốn chia sẻ kiến thức và thông tin của họ với các nhà phát triển khác. Vì vậy, tôi nghĩ sẽ thật tuyệt nếu tôi có thể tiếp tục chia sẻ nó và giúp những người khác sử dụng nó.

Lúc đầu, tôi cố gắng chia sẻ một vài ghi chú hoặc slide, nhưng tôi cảm thấy nó chưa đủ tốt, ít nhất là không tốt như những gì người nói đã chia sẻ với tôi. Vì vậy, tôi quyết định xem lại từng bài phát biểu, đi sâu hơn vào chúng, tìm kiếm, ghi chú và kết hợp chúng với các trang trình bày và thậm chí cả những từ chính xác trong bài phát biểu của họ và sau đó chia sẻ với bạn để những gì tôi chia sẻ với bạn ít nhất là cùng cấp độ với những gì tôi học được từ họ.

Một điểm rất quan trọng

Tất cả những gì bạn đọc được trong vài bài báo này là kết quả của nỗ lực và thời gian của chính người nói, và tôi chỉ cố gắng học hỏi chúng để có thể biến chúng thành những bài báo này. Thậm chí nhiều câu được viết trong những bài báo này chính xác là những gì họ đã nói hoặc những gì họ đã viết trong Trang trình bày. Điều này có nghĩa là nếu bạn học được điều gì đó mới, đó là do nỗ lực của họ. (Vì vậy, nếu bạn thấy một số thông tin sai lệch, hãy đổ lỗi cho họ, không phải tôi, phải không? XD)

Cuối cùng nhưng không kém phần quan trọng, tôi có thể không đào sâu vào từng chi tiết kỹ thuật hoặc mã hóa trực tiếp trong một số bài phát biểu. Nhưng nếu bạn quan tâm và cần thêm thông tin, hãy cho tôi biết và tôi sẽ cố gắng viết riêng một bài chi tiết hơn. Ngoài ra, đừng quên kiểm tra Twitter / Linkedin của họ.

Tại đây bạn có thể tìm thấy chương trình của hội nghị.

Đó là một cái bẫy (Thử nghiệm)! Cạm bẫy thử nghiệm phổ biến và cách giải quyết chúng

Ramona Sch tower - Nhà phát triển phần mềm tại shopware

“Đó là một cái bẫy” - một cách gọi hoặc cảm giác mà tất cả chúng ta có thể quen thuộc, không chỉ khi nói đến Chiến tranh giữa các vì sao. Nó báo hiệu một khoảnh khắc bất ngờ nhận thấy nguy hiểm sắp xảy ra.

Tình huống này là một câu chuyện ngụ ngôn tuyệt vời cho một hiện thực khó chịu trong thử nghiệm. Hãy tưởng tượng bạn có ý định tốt nhất khi nói đến thử nghiệm, nhưng vẫn kết thúc với các thử nghiệm không mang lại cho bạn bất kỳ giá trị nào?

Thử nghiệm ai đang cảm thấy như một nỗi đau để đối phó?

Khi viết bài kiểm tra giao diện người dùng, có rất nhiều cạm bẫy trên đường đi. Tóm lại, chúng có thể dẫn đến khả năng bảo trì tệ hại, thời gian thực thi chậm và - trong trường hợp xấu nhất - các bài kiểm tra bạn không thể tin tưởng.

Nhưng điều tồi tệ nhất là những bài kiểm tra mang lại cho bạn giá trị và kết quả mới bởi vì chúng bị bong tróc. Bạn có một công trình xây dựng đôi khi vượt qua và đôi khi thất bại và bạn không làm gì ở giữa.

Điểm đau

Bạn có thể chắc chắn rằng thử nghiệm có nhiều đặc quyền và lợi thế, nhưng tất cả những điều tuyệt vời đó có thể bị che lấp bởi những điểm đau do nhiều lý do khác nhau. Tất cả những điều bạn đã làm với mục đích tốt nhất nhưng về lâu dài hoặc thậm chí sớm hơn chúng sẽ trở nên đau đớn hoặc mệt mỏi.

Ví dụ, các bài kiểm tra chậm có thể giết chết niềm vui. Hãy tưởng tượng bạn có yêu cầu kéo của mình và bạn muốn nó được hợp nhất, nhưng bạn cần đợi hàng giờ hoặc có thể vài ngày để đường ống cuối cùng được hoàn thành.

Tệ hơn nữa là những bài kiểm tra rất khó để duy trì. Bạn nghĩ về quá khứ của mình và bạn hỏi: Bạn đã làm gì với bài kiểm tra này? Mục đích là gì ?! Bạn nghĩ gì về điều đó? Hoặc các thành viên khác trong nhóm đang đặt câu hỏi cho bạn về những gì bạn đã làm trong quá khứ và bạn không có manh mối.

Nhưng điều tồi tệ nhất là những bài kiểm tra mang lại cho bạn giá trị và kết quả mới bởi vì chúng bị bong tróc. Bạn có một công trình xây dựng đôi khi vượt qua và đôi khi thất bại và bạn không làm gì ở giữa.

Kiểm tra đơn giản

Nó không cần phải theo cách này. Một trong những tư duy quan trọng nhất và các quy tắc vàng trong các phương pháp hay nhất để kiểm tra JavaScript là Đơn giản.

Các bài kiểm tra nên được thiết kế đơn giản và dễ hiểu trong mọi trường hợp. Trong các bài kiểm tra đơn vị, kiểm tra tích hợp và kiểm tra End to End, hãy đơn giản hóa nó.

Mục tiêu của chúng tôi phải là một người có khả năng hiểu bài kiểm tra của bạn và nhận được ý định của nó ngay lập tức mà không cần suy nghĩ về nó.

Cố gắng hướng tới một thiết kế thử nghiệm phẳng, có nghĩa là chỉ thử nghiệm càng nhiều càng tốt và sử dụng ít hoặc không có sự trừu tượng nào cả.

Bẫy

Hãy xem Trap đầu tiên.

 describe('deprecated.plugin', () => { it('should throw error',() => { … }); });

Nó sẽ xuất hiện một lỗi nếu plugin không dùng nữa đang được sử dụng.

Khi bạn nhìn vào tiêu đề - sẽ phát sinh lỗi - bạn không biết nó muốn đạt được điều gì. Nhưng Quy tắc vàng nói rằng bạn nên biết ngay lập tức nó đang làm gì.

Chúng ta có thể làm cho nó dễ hiểu hơn với "Quy tắc ba phần". Tiêu đề thử nghiệm nên chứa ba điều:

1. Những gì đang được thử nghiệm
2. Trong những trường hợp nào nên được kiểm tra
3. Kết quả được mong đợi là gì

Với quy tắc này trong tâm trí, đây là bài kiểm tra của chúng tôi sẽ trông như thế nào:

 describe('deprecated.plugin', () => { it('Property: Should throw an errorif the deprecated prop is used', () => { … }); });

Bẫy tiếp theo có thể là cấu trúc kiểm tra:

 describe('Context menu', () => { it('should open the context menu on click', async () => { const wrapper = createWrapper(); expect(wrapper.vm).toBeTruthy(); await wrapper.trigger('click'); const selector = '.sw-context-menu'; expect(wrapper.find(selector).isVisible()).toBeTruthy(); }); });

Trong trường hợp này, các khai báo, hành động và xác nhận được viết ở khắp nơi mà không có bất kỳ cấu trúc rõ ràng nào. Đặc biệt là trong các thử nghiệm lớn hơn, đây có thể là một nỗi đau rất lớn. Chúng tôi có thể làm cho nó có cấu trúc hơn với AAA Pattern. Bạn chia bài kiểm tra của mình thành ba phần:

1. Sắp xếp: Mọi thứ liên quan đến thiết lập kịch bản mà thử nghiệm nhằm mục đích mô phỏng.
2. Hành động: Chạy đơn vị của bạn trong bài kiểm tra và thực hiện các bước để đến trạng thái kết quả.
3. Khẳng định: Nơi bạn có thể thực hiện các xác nhận và kiểm tra kịch bản thử nghiệm của mình.

Đây là thử nghiệm của chúng tôi trông như thế nào với Mẫu AAA:

 describe('Context menu', () => { it('should open the context menu on click', () => { // Arrange const wrapper = createWrapper(); const selector = '.sw-context-menu'; // Act await wrapper.trigger('click'); // Assert expect(wrapper.vm).toBeTruthy(); expect(wrapper.find(selector).isVisible()).toBeTruthy(); }); });

Điều này trông tốt hơn nhiều!

Nhưng có một vấn đề. Hãy nghĩ lại trường hợp thử nghiệm của chúng tôi. Nó là một menu ngữ cảnh và nó bị ẩn theo mặc định. Vì vậy, chúng ta cần mở nó ra để tương tác với nó. Nhưng nó có nghĩa là chúng ta cần phải xác nhận để đảm bảo rằng nó sẽ mở trước khi hành động. Nó không phá hủy khuôn mẫu sao?

Nếu chúng tôi đang kiểm tra DOM, đôi khi chúng tôi cần kiểm tra trạng thái trước và sau. Vì vậy, chúng ta hãy nhìn vào mô hình này từ một góc độ khác.

• … Sắp xếp bài kiểm tra của tôi == những gì tôi được giao .
• … Hành động trong bài kiểm tra của tôi == khi có điều gì đó xảy ra.
• … Khẳng định kết quả == có điều gì đó xảy ra thì đây là kết quả mà tôi mong đợi.

Đây là một mô hình được lấy từ sự phát triển theo định hướng hành vi: Cho trước - Khi nào - Sau đó

Thử nghiệm trước của chúng tôi với việc sử dụng mẫu này:

 describe('Context menu', () => { it('should open the context menu on click', () => { // Given const contextButtonSelector = 'sw-context-button'; const contextMenuSelector = '.sw-context-menu'; // When let contextMenu = wrapper.find(contextMenuSelector); expect(contextMenu.isVisible()).toBe(false); const contextButton = wrapper.find(contextButtonSelector); await contextButton.trigger('click'); // Then contextMenu = wrapper.find(contextMenuSelector); expect(contextMenu.isVisible()).toBe(true); }); });

Kiểm tra E2E

Tránh sử dụng trình giữ chỗ và đặt tên thực tế càng nhiều càng tốt.

 it('should create and read product', () => { … cy.get('.sw-field—product-name').type('T-Shirt Ackbar'); cy.get('.sw-select-product__select_manufacturer') .type('Space Company'); … });

Nếu bạn không muốn nghĩ ra hàng nghìn tên, có thể bạn có thể sử dụng faker hoặc các công cụ khác để tạo một số dữ liệu giả hoặc nếu ổn với luật và dự án của bạn, hãy nhập dữ liệu đó từ trạng thái sản xuất. Chỉ cần đảm bảo rằng bài kiểm tra của bạn luôn dễ hiểu, dễ đọc và bạn biết nó làm gì.

Chúng ta hãy xem xét thử nghiệm tương tự cho cái bẫy tiếp theo, đó là bộ chọn.

Nếu bạn cấu trúc lại ứng dụng của mình và thay đổi một số lớp - điều này là phổ biến - điều này có thể khiến thử nghiệm của bạn không thành công và trong trường hợp này, thử nghiệm không thành công mà không có lỗi trong ứng dụng của bạn - được gọi là âm tính giả không đưa ra báo cáo đáng tin cậy về ứng dụng vì nó không bị hỏng, chỉ là cách triển khai của bạn đã thay đổi.

Nhìn vào bộ chọn bạn phải! Nói cách khác, bạn không nên kiểm tra chi tiết triển khai. Thay vào đó, hãy nghĩ về việc sử dụng những thứ mà người dùng sẽ thu hút sự chú ý và điều hướng ứng dụng của bạn. Ví dụ: một số văn bản bên trong trang của bạn. Tốt hơn nữa, hãy sử dụng các bộ chọn không dễ bị thay đổi, chẳng hạn như các thuộc tính dữ liệu. Bạn thậm chí có thể gọi nó là ví dụ cho cypress data-cy=”submit” để người ta biết ngay rằng nó dùng để thử nghiệm.

Cuối cùng nhưng không kém phần quan trọng, không sử dụng thời gian chờ cố định.

 Cypress.Commands.add('typeSingleSelect', { prevSubject: 'element', }, (subject, value, selector) => { … cy.wait(500); cy.get(`${selector} input`) .type(value); });

Mặt khác, điều đó có thể làm chậm quá trình thử nghiệm của bạn quá nhiều nếu một trường hợp thử nghiệm sẽ được thực thi nhiều lần. Nó thậm chí có thể tồi tệ hơn khi ứng dụng của bạn đang được sử dụng trên phần cứng yếu hơn. Trong trường hợp này, bạn có thể cần nhiều hơn 500ms sửa chữa.

Có một số giải pháp cho điều đó, chẳng hạn như đợi những thay đổi trong giao diện người dùng, chẳng hạn như trình quay vòng tải biến mất hoặc hoạt ảnh dừng hoặc thứ gì đó xuất hiện.

Hoặc thậm chí tốt hơn, hãy đợi các Yêu cầu và Phản hồi API.

Kiểm tra ở đó như một trợ lý cho bạn, không phải là một trở ngại. Họ sẽ cảm thấy như một thói quen không giống như giải một công thức toán học phức tạp.

Kết thúc cuộc nói chuyện thứ sáu

Tôi hy vọng bạn thích phần này và nó có thể có giá trị đối với bạn cũng như đối với tôi. Trong vài ngày tới, tôi sẽ chia sẻ phần còn lại của cuộc nói chuyện với bạn. Giữ nguyên…

Cũng được xuất bản ở đây .