Các kịch bản BDD có nên bao gồm dữ liệu thử nghiệm thực tế hay chỉ mô tả nó?

Question

Chúng tôi đã đến điểm mà chúng tôi đã nhận ra rằng có hai tùy chọn để chỉ định dữ liệu thử nghiệm khi xác định kịch bản CRUD điển hình:

Tùy chọn 1: Mô tả dữ liệu để sử dụng và để thực hiện xác định dữ liệu

Scenario: Create a region 
    Given I have navigated to the "Create Region" page 
     And I have typed in a valid name 
     And I have typed in a valid code 
    When I click the "Save" button 
    Then I should be on the "Regions" page 
    And the page should show the created region details 

Phương án 2: rõ ràng nêu dữ liệu thử nghiệm sử dụng

Scenario: Create a region 
    Given I have navigated to the "Create Region" page 
     And I have filled out the form as follows 
     | Label | Value | 
     | Name | Europe | 
     | Code | EUR | 
    When I click the "Save" button 
    Then I should be on the "Regions" page 
    And the page should show the following fields 
     | Name | Code | 
     | Europe | EUR | 

Xét về lợi ích phù hợp và hạn chế, những gì chúng tôi đã thiết lập là:

Tùy chọn 1 độc đáo đề cập đến trường hợp khi định nghĩa nói "thay đổi tên hợp lệ". Điều này có thể khó giải quyết hơn nếu chúng tôi đi với Tùy chọn 2, nơi dữ liệu thử nghiệm ở một vài nơi. Tùy chọn 1 mô tả một cách rõ ràng những gì quan trọng về dữ liệu cho thử nghiệm này, đặc biệt nếu đó là một kịch bản mà chúng tôi đã nói điều gì đó như "đã nhập vào số thẻ tín dụng không hợp lệ". Nó cũng "cảm thấy" trừu tượng hơn và BDD bằng cách nào đó, quan tâm nhiều hơn đến mô tả hơn là thực hiện.

Tuy nhiên, Tùy chọn 1 sử dụng các bước rất cụ thể khó tái sử dụng. Ví dụ: "trang sẽ hiển thị chi tiết vùng được tạo" có thể chỉ được sử dụng bởi trường hợp này. Ngược lại, chúng tôi có thể thực hiện Tùy chọn 2 "trang sẽ hiển thị các trường sau" theo cách có thể sử dụng lại nhiều lần theo các trường hợp khác.

Tôi cũng nghĩ Tùy chọn 2 có vẻ thân thiện với khách hàng hơn, vì họ có thể thấy bằng ví dụ những gì đang xảy ra thay vì phải diễn giải các thuật ngữ trừu tượng hơn như "hợp lệ". Tùy chọn 2 có giòn hơn không? Tái cấu trúc mô hình có thể có nghĩa là phá vỡ các thử nghiệm này, trong khi nếu dữ liệu thử nghiệm được xác định trong mã trình biên dịch sẽ giúp chúng ta thay đổi mô hình.

Tôi đánh giá cao rằng sẽ không có câu trả lời đúng hay sai ở đây, nhưng muốn nghe ý kiến ​​của mọi người về cách họ quyết định nên sử dụng cái gì.

Cảm ơn!

Answer 1

Tôi sẽ nói điều đó tùy thuộc. Có những lúc một Kịch bản có thể yêu cầu một lượng lớn dữ liệu để hoàn thành một lần chạy thành công. Thông thường, phần lớn dữ liệu đó không quan trọng đối với điều chúng tôi đang thực sự thử nghiệm và do đó trở thành tiếng ồn mất tập trung từ sự hiểu biết mà chúng tôi đang cố gắng đạt được với Kịch bản.Tôi bắt đầu sử dụng thứ gì đó mà tôi gọi là mẫu Dữ liệu mặc định để cung cấp dữ liệu mặc định có thể được hợp nhất với dữ liệu cụ thể cho Kịch bản. Tôi đã viết về nó ở đây:

http://www.cheezyworld.com/2010/11/21/ui-tests-default-dat/

Tôi hy vọng điều này sẽ hữu ích.

Answer 2

Tôi thích tùy chọn 2.

Cho người dùng doanh nghiệp, ngay lập tức xóa đầu vào và đầu ra. Với tùy chọn 1, chúng tôi không biết dữ liệu hợp lệ là gì, vì vậy việc triển khai của bạn có thể sai.

Bạn thậm chí có thể biểu cảm hơn bằng cách thêm dữ liệu không hợp lệ quá, khi thích hợp

Scenario: Filter for Awesome 
    Given I have navigated to the "Show People" page 
    And I have the following data 
    | Name | Value | 
    | John | Awesome| 
    | Bob | OK  | 
    | Jane | Fail | 
When I click the "Filter" button 
Then the list should display  
    | Name | Value | 
    | John | Awesome | 

Bạn tuy nhiên nên giữ cho dữ liệu để mô tả nó về tên miền, đúng hơn là việc thực hiện cụ thể. Điều này sẽ cho phép bạn kiểm tra ở các lớp khác nhau trong ứng dụng của bạn. ví dụ. Dịch vụ UI vv ..

Answer 3

Mỗi lần tôi nghĩ về điều này, tôi thay đổi quyết định. Nhưng nếu bạn nghĩ về nó - thử nghiệm là để chứng minh rằng bạn có thể tạo ra một khu vực. Một Tiêu chí được đáp ứng bởi cả hai tùy chọn. Nhưng tôi đồng ý rằng các tín hiệu trực quan với tùy chọn 2 và sự thân thiện với nhà phát triển có lẽ là quá tốt để từ chối. Trong những ví dụ như thế này, ít nhất.