Làm thế nào để lựa chọn giữa các loại thử nghiệm khác nhau với khung kiểm tra chấp nhận SpecFlow, Cucumber hoặc BDD khác?

Question

Tôi đang tìm các ví dụ SpecFlow, và đó là mẫu MVC chứa một số lựa chọn thay thế để thử nghiệm: thử nghiệm

• chấp nhận dựa trên việc chứng thực kết quả được tạo bởi bộ điều khiển;
• Kiểm tra tích hợp bằng MvcIntegrationTestFramework;
• Kiểm tra chấp nhận tự động bằng Selenium;
• Kiểm tra chấp nhận thủ công khi người kiểm tra được nhắc xác thực kết quả theo cách thủ công.

Tôi phải nói rằng tôi khá ấn tượng với các ví dụ SpecFlow được viết (và tôi quản lý để chạy chúng trong vòng vài phút sau khi tải xuống, chỉ cần cấu hình cơ sở dữ liệu và cài đặt máy chủ điều khiển từ xa Selenium). Nhìn vào các lựa chọn thay thế thử nghiệm tôi có thể thấy rằng hầu hết trong số họ bổ sung cho nhau thay vì là một thay thế. Tôi có thể nghĩ về các kết hợp sau đây của các thử nghiệm này:

• Bộ điều khiển được thử nghiệm theo kiểu TDD thay vì sử dụng SpecFlow (Tôi cho rằng/Khi/Sau đó, loại thử nghiệm nên được áp dụng ở cấp cao hơn, từ đầu đến cuối chúng phải cung cấp độ bao phủ mã tốt cho các thành phần tương ứng,
• MvcIntegrationTestFramework rất hữu ích khi chạy thử nghiệm tích hợp trong các phiên phát triển, các thử nghiệm này cũng là một phần của các bản xây dựng hàng ngày; chủ yếu được bắt đầu trong các phiên QA, để xác thực nhanh chóng rằng không có logic bị hỏng trong các trang và quy trình làm việc của trang;
• Kiểm tra chấp nhận thủ công khi người kiểm tra được nhắc xác nhận tính hợp lệ của kết quả chủ yếu để xác minh giao diện trang.

Nếu bạn sử dụng khung kiểm tra chấp nhận SpecFlow, Cucumber hoặc BDD khác trong phát triển Web, bạn có thể chia sẻ thực tiễn về lựa chọn giữa các loại thử nghiệm khác nhau hay không.

Xin cảm ơn trước.

Answer 1

Đó là tất cả hành vi.

Với một ngữ cảnh cụ thể, khi một sự kiện xảy ra (trong phạm vi một phạm vi cụ thể), thì một số kết quả sẽ xảy ra.

Phạm vi có thể là toàn bộ ứng dụng, một phần của hệ thống hoặc một lớp đơn lẻ. Ngay cả một hàm hoạt động theo cách này, với các đầu vào như ngữ cảnh và đầu ra là kết quả (bạn cũng có thể sử dụng BDD cho ngôn ngữ chức năng!)

Tôi có xu hướng sử dụng các khung đơn vị (NUnit, JUnit, RSpec, v.v.) ở cấp lớp hoặc mức tích hợp, vì đối tượng là kỹ thuật. Đôi khi tôi ghi lại các Cho/Khi/Sau đó trong ý kiến.

Ở cấp độ kịch bản, tôi cố gắng tìm ra ai thực sự muốn giúp đọc hoặc viết kịch bản. Ngay cả các bên liên quan cũng có thể đọc văn bản có chứa một vài dấu chấm và dấu ngoặc, vì vậy lý do chính để có khung ngôn ngữ tự nhiên như MSpec hoặc JBehave là nếu họ muốn viết kịch bản hoặc hiển thị chúng cho những người thực sự bị xóa bởi dấu chấm và dấu ngoặc vuông.

Sau đó, tôi xem xét cách khung sẽ chơi với hệ thống xây dựng và cách chúng tôi sẽ cung cấp khả năng đọc hoặc viết phù hợp với các bên liên quan quan tâm.

Here's an example I wrote để hiển thị loại điều bạn có thể thực hiện với các tình huống bằng DSL đơn giản. Điều này chỉ được viết bằng NUnit.

Here's an example in the same codebase hiển thị Được, Khi, Sau đó, trong nhận xét mẫu ở cấp lớp.

Tôi trừu tượng các bước sau, sau đó tôi đặt màn hình hoặc trang phía sau, sau đó trên màn hình và trang tôi gọi bất kỳ khung tự động nào tôi đang sử dụng - có thể là Selenium, Watir, WebRat, Microsoft UI Automation, v.v.

Ví dụ tôi cung cấp là một công cụ tự động hóa, vì vậy các tình huống thể hiện hành vi của công cụ tự động hóa thông qua việc chứng minh hành vi của một gui giả, chỉ trong trường hợp bị nhầm lẫn. Hy vọng nó sẽ giúp anyway!

Answer 2

Vì thử nghiệm chấp nhận là một loại thử nghiệm chức năng, mục tiêu chung là kiểm tra ứng dụng của bạn với chúng end-to-end. Mặt khác, bạn có thể cần phải xem xét hiệu quả (bao nhiêu nỗ lực là để thực hiện tự động hóa thử nghiệm), bảo trì, hiệu suất và độ tin cậy của tự động hóa thử nghiệm. Điều cũng quan trọng là việc tự động hóa thử nghiệm có thể dễ dàng phù hợp với quy trình phát triển, do đó nó hỗ trợ một loại phương pháp "thử nghiệm đầu tiên" (để hỗ trợ phát triển bên ngoài).

Vì vậy, đây là một sự cân bằng, điều này có thể khác nhau đối với từng trường hợp (đó là lý do chúng tôi cung cấp các lựa chọn thay thế).

Tôi chắc chắn rằng, hôm nay tùy chọn phù hợp nhất là kiểm tra ở lớp bộ điều khiển. (Có thể sau đó là khung giao diện người dùng tự động và giao diện người dùng sẽ phát triển, điều này sẽ thay đổi.)