Hiểu BDD với một ví dụ thực tế

Question

Tôi đang cố gắng tham gia vào cách tiếp cận phát triển theo hành vi, nhưng để sử dụng nó tôi cần phải hiểu cách suy nghĩ theo cách đó.

Tôi muốn thử nghiệm nó trên một dự án cá nhân mới tôi bắt đầu ngay bây giờ (tôi sẽ sử dụng ROR)

Dự án sẽ cung cấp API để thu thập dữ liệu từ các ứng dụng bên ngoài, nó sẽ cung cấp một chứng thực hệ thống (đưa ra), một số mô hình để thu thập dữ liệu khi cần và hệ thống thanh toán để mua đăng ký sẽ cung cấp một số tính năng chỉ cao cấp.

Tôi nên thực hiện các loại thử nghiệm nào để trang trải tất cả các chức năng này nhưng DRY?

Tôi nghĩ mình nên sử dụng cả RSpec và Cucumber. Đối với Devise tôi sẽ làm theo tài liệu trên trang web của họ, nhưng không rõ tôi nên kiểm tra loại dữ liệu nào để kiểm tra dữ liệu đã được thu thập chính xác và nó được hiển thị chính xác cho người dùng và công cụ nào sử dụng cho tác vụ đó. Ngoài ra, nếu bạn có thể cung cấp một ví dụ đơn giản về việc bạn sẽ tổ chức các thử nghiệm và phát triển cho loại dự án này như thế nào (tôi không hỏi về mã thử nghiệm thực - vì tôi thấy nó thực sự phụ thuộc vào việc triển khai, nhưng về quy trình phát triển và LOẠI các bài kiểm tra bạn sẽ thực hiện). Nếu bạn cần một số chi tiết khác để có một sự lựa chọn, xin vui lòng cho tôi biết và cảm thấy tự do để phát minh ra nó vì nó cho mục đích giáo dục.

Answer 1

Tôi không nghĩ rằng có thể có bất kỳ đề cập đến BDD mà không một người nào đó chiming ở chỗ nó là tất cả về giao tiếp. Vì vậy, tôi sẽ là anh chàng đó: đó là tất cả về thông tin liên lạc! Giá trị thực là việc khám phá chức năng trong các điều khoản có thể truy cập với các bên liên quan khác nhau để thiết lập những gì hệ thống cần làm một cách minh bạch. Với tất cả mọi người nói cùng một ngôn ngữ, việc giao tiếp mục tiêu dễ dàng hơn nhiều. Khi nói đến việc triển khai, các nhà phát triển biết họ đang làm gì, các bên liên quan biết họ đang nhận được gì và không nên có quá nhiều điều bất ngờ (ngoại trừ những điều bạn bỏ lỡ/bị bắt không chính xác/chưa nhận ra).

Vì vậy, hãy ra khỏi đó, nói chuyện với các bên liên quan của bạn và làm việc ra những gì người ủy quyền hệ thống muốn nó làm.Nếu đây là một nỗ lực solo, bạn sẽ cần phải mặc một số mũ khác nhau.

Kiểm tra BDD của bạn sẽ bao gồm hành vi của hệ thống - các đơn vị chức năng mong muốn. Bạn vẫn sẽ cần phải làm bài kiểm tra đơn vị vv - không có thay đổi ở đó.

Là chủ sở hữu sản phẩm, hãy suy nghĩ về những gì bạn muốn hệ thống làm - không phải cách. Bạn có thể không quan tâm cách mọi thứ hoạt động, miễn là chúng hoạt động. Nếu bạn là nhà phát triển, điều này có thể sẽ là sự thay đổi khó khăn trong suy nghĩ. Khi lần đầu tiên tôi bắt đầu xem xét BDD, tôi đã tin rằng nó có ý nghĩa để đi qua các hành trình giao diện người dùng và các chi tiết kỹ thuật, vv trong các tình huống. Nó không có. Nội dung đó thuộc về các định nghĩa bước. Là nhà phát triển, bạn có thể xác định tất cả các cách thức hoạt động của ở đó.

Để giữ cho nó KHÔNG BIẾT… Viết kịch bản của bạn chính xác cách bạn cần để nắm bắt hành vi được yêu cầu. Sau đó, bạn có thể lo lắng về việc tái cấu trúc và xác định các cơ hội để sử dụng lại bước. Việc sử dụng các biểu thức thông thường cũng sẽ giúp ở đây, ở một mức độ nào đó. Thật là hấp dẫn khi bắt đầu siêu đẳng cấp và có toàn bộ các bước có thể sử dụng lại, nhưng bạn có thể nhận ra rằng tất cả đều rất dễ vỡ khi thay đổi một bước gợn sóng thông qua tất cả các kịch bản của bạn, không chỉ có ảnh hưởng đến. Nếu bạn quan tâm đến bất kỳ hình thức tự động hóa web nào, hãy xem kim tự tháp hóa web.

nguồn lực hữu ích (và rất nhiều ví dụ):

http://books.openlibra.com/pdf/cuke4ninja-2011-03-16.pdf < tuyệt vời eBook miễn phí - thú vị để đọc, quá.

http://www.slideshare.net/lunivore/behavior-driven-development-11754474 < Liz thực sự biết nội dung của cô ấy!

http://dannorth.net/2011/01/31/whose-domain-is-it-anyway/

https://www.google.co.uk/search?q=declarative+vs+imperative+BDD < đi Đội Declarative!

Answer 2

Tôi không chắc chắn này đáp ứng các yêu cầu chính xác của bạn, nhưng đây là cách tôi làm BDD (ví dụ là một webapp):

Giả vờ bạn đang ngồi ở phía trước của máy tính như một người dùng của ứng dụng của bạn. Viết ra các bước bạn cần phải thực hiện để đạt được một trong những trường hợp sử dụng, ví dụ:

Navigate to của hệ thống url Đăng nhập Chọn chức năng bạn cần Nhập dữ liệu có liên quan để thực hiện chức năng Nhấp vào nút để bắt đầu chức năng Đợi hệ thống phản hồi Đảm bảo dữ liệu trên màn hình khớp với dữ liệu bạn mong đợi.

Nếu bất kỳ bước nào trong số các bước này không thực thi hoặc dữ liệu không chính xác, kiểm tra đã không thành công.

Khi bạn có tệp này trong tệp thử nghiệm, bạn sử dụng Gherkin/Cucumber/Webdriver để triển khai mã cần thiết để thực thi từng bước. Mỗi phương pháp này có thể sử dụng lại được, vì vậy khi bạn đã đăng nhập ở một nơi, nó sẽ hoạt động ở mọi nơi bạn gọi nó.

Answer 3

để thử nghiệm với dưa chuột hoặc rspec cho devise thử này

thấy điều này - cucumber/rspec hoặc on github