Sử dụng SpecFlow để kiểm tra hồi qui từ đầu đến cuối

Question

Chúng tôi đang sử dụng BDD và sử dụng SpecFlow để thúc đẩy sự phát triển của chúng tôi (ATDD).

Nhóm QA của chúng tôi muốn xác định các thử nghiệm hồi quy đầu cuối của riêng mình (trong Gherkin/SpecFlow) và tái sử dụng các bước mà chúng tôi đã xác định.

(Xin lưu ý - Tôi biết rằng đây không phải là một ví dụ tuyệt vời nhưng nó phải cung cấp đủ thông tin chi tiết)

Xét nghiệm có thể bao gồm ..

1. Đăng nhập
2. Tìm kiếm một sản phẩm
3. Chọn sản phẩm để mua
4. Tạo đơn đặt hàng
5. Chọn tùy chọn phân phối.
6. Gửi đơn đặt hàng.
7. Hủy đơn đặt hàng.

sẽ Điều này cho thấy một kịch bản như ..

Given Tôi đăng nhập
Khi tôi Tìm kiếm một sản phẩm
Và tôi Chọn một sản phẩm để mua
Và tôi Tạo đơn đặt
Và Tôi Chọn tùy chọn phân phối
Và tôi Gửi đơn đặt hàng
Và tôi Hủy đơn đặt hàng
Sau đó ?? !!

Điều này rõ ràng là sai vì chúng tôi không kiểm tra đầu ra ở từng bước.

Vì vậy này có thể được giải quyết như một chuỗi các kịch bản:

Kịch bản 1:
Với tôi đăng nhập
Khi tôi Tìm kiếm một sản phẩm
Sau đó, tôi nhìn thấy một danh sách các sản phẩm

Kịch bản 2:
Khi tôi chọn một sản phẩm để mua
Sau đó, tôi có thể tạo đơn đặt hàng

Kịch bản 3:
Khi tôi tạo ra thứ tự
Và tôi Chọn tùy chọn phân phối
Sau đó, tôi có thể gửi lệnh

vv vv

Vấn đề chính với điều này là rằng có vẻ như không có cách để xác định thứ tự/chuỗi mà các kịch bản được chạy trong (một đặc tính của nUnit?). Bởi vì có sự phụ thuộc giữa các kịch bản (chúng không được thiết lập cho một điểm bắt đầu biết) chúng phải được chạy theo thứ tự.

Câu hỏi của tôi là:

a) Chúng tôi đang cố gắng vừa với một chốt vuông trong một lỗ tròn?!

b) Có ai biết nếu có cách sử dụng SpecFlow/Gherkin theo cách này không?

c) Hoặc có ai biết lựa chọn thay thế nào không?

Rất cám ơn!

Answer 1

Tôi sẽ nói rằng bạn đang viết kịch bản của mình ở mức trừu tượng sai. Nhưng điều đó phụ thuộc vào những gì bạn muốn sử dụng chúng;

Nếu bạn muốn viết kịch bản thử nghiệm thì bạn đang đi đúng hướng ... nhưng nó sẽ là một cơn ác mộng để duy trì vì nó, trong trường hợp đầu tiên (kịch bản dài) sẽ rất giòn và trường hợp thứ hai (một số kịch bản) cần phải đảm bảo một lệnh thực hiện nhất định. Cả hai đều không được khuyến khích và được coi là chống mẫu.

Tôi khuyên bạn nên hợp nhất các bài kiểm tra ATDD mà bạn đang viết và trao đổi với bộ phận kiểm tra để xem xét vấn đề và bao gồm các trường hợp kiểm tra cần đảm bảo rằng hệ thống được kiểm tra kỹ lưỡng. Ai biết? Bạn thậm chí có thể học hỏi điều gì đó từ mỗi khác: P

Và khi bạn viết những "thông số kỹ thuật" (như tôi thích gọi chúng), bạn viết chúng ở mức cao hơn. Vì vậy, thay vì viết:

Given I am logged in 
When I Search for a product 
    And I Select a product to buy 
    And I Create an order 
    And I Select delivery option 
    And I Submit the order 

bạn viết một cái gì đó giống như

When I submit an order for product 'Canned beans' 

Trong bước định nghĩa đằng sau bước mà bạn thực hiện tất cả những gì tự động hóa (đăng nhập, duyệt đến trang sản phẩm, chọn các tùy chọn giao hàng, gửi đơn đặt hàng).

Tất cả điều này có thể được đọc trong những bài viết tuyệt vời về cách viết duy trì kiểm tra giao diện người dùng tự động hóa:

• http://gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/
• http://elabs.se/blog/15-you-re-cuking-it-wrong
• http://www.marcusoft.net/2011/04/clean-up-your-stepsuse-page-objects-in.html
• http://dhemery.com/pdf/writing_maintainable_automated_acceptance_tests.pdf
• http://gojko.net/2010/01/05/bdd-in-net-with-cucumber-part-3-scenario-outlines-and-tabular-templates/
• http://chrismdp.github.com/2011/09/layers-of-abstraction-writing-great-cucumber-code/
• http://benmabey.com/2008/05/19/imperative-vs-declarative-scenarios-in-user-stories.html
• http://mislav.uniqpath.com/2010/09/cuking-it-right/

Tôi hy vọng điều này sẽ giúp