Làm thế nào để sử dụng các bài kiểm tra đơn vị khi sử dụng BDD?

Tôi đang cố gắng để hiểu BDD. Tôi đã đọc một số bài báo và theo tôi hiểu thì BDD là "bước tiếp theo" từ TDD. Tôi nói điều đó bởi vì tôi thấy cả hai đều rất giống nhau và như tôi có thể đọc trong bài viết này , BDD được sinh ra như một sự cải tiến từ TDD. Tuyệt vời, tôi thực sự thích ý tưởng.

Có một điểm thực tế mà tôi không nhận được, đó là: có một tệp .feature trong đó BA sẽ viết tất cả các hành vi dự kiến ​​mà hệ thống sẽ có. Là một BA, anh ta không biết hệ thống được xây dựng như thế nào, vì vậy chúng tôi sẽ viết một cái gì đó như thế này:

+ Kịch bản 1: Tài khoản đang trong tín dụng +

Cho tài khoản là tín dụng

Và thẻ hợp lệ

Và bộ phân phối chứa tiền mặt

Khi khách hàng yêu cầu tiền mặt

Sau đó, đảm bảo tài khoản được ghi nợ Và đảm bảo tiền mặt được phân phối

Và đảm bảo thẻ được trả lại

Ok, điều này thật tuyệt, nhưng có nhiều phần của hệ thống sẽ hợp tác để nó có thể xảy ra (nghĩ về Account obj, nóng lạnh obj, obj của khách hàng, v.v.). Đối với tôi điều này trông giống như một bài kiểm tra tích hợp.

Tôi muốn có bài kiểm tra đơn vị. Làm cách nào để kiểm tra mã kiểm tra xem bộ phân phối có tiền không? Hoặc là tiền mặt được phân phối? Hoặc tài khoản bị ghi nợ khi được yêu cầu? Làm cách nào tôi có thể kết hợp các bài kiểm tra đơn vị với các bài kiểm tra "BA Tạo"?

Phát triển hướng hành vi và phát triển hướng thử nghiệm là miễn phí, nhưng không thay thế cho nhau.

Cách ứng dụng "ứng xử" được mô tả trong Các bài kiểm tra chấp nhận, theo BDD sẽ là các Tính năng và Kịch bản được viết trong Cucumber.

Các chi tiết khó chịu về cách thức hoạt động của từng thành phần nhỏ được mô tả trong Bài kiểm tra đơn vị. Các kết quả của Bài kiểm tra đơn vị hỗ trợ các Kịch bản bạn viết trong Dưa chuột.

Hãy tưởng tượng quá trình xây dựng một chiếc xe hơi.

Đầu tiên, nhóm sản phẩm đưa ra ý tưởng của họ và cuối cùng đưa họ vào các tình huống sử dụng:

Scenario: Starting the car
    Given I am standing in front of the drivers door
    When I open the door
    Then the door should lift up DeLorean-style (yeah, baby!)
    When I get into the car
    And turn the key
    Then the engine roars to life

Tôi biết kịch bản này nghe có vẻ hơi ngớ ngẩn, nhưng nó là một yêu cầu tập trung vào sản phẩm và người dùng cuối rất cao. Chỉ cần mở cửa, vặn chìa khóa và khởi động động cơ bao gồm rất nhiều thành phần khác nhau làm việc cùng nhau. Thử nghiệm này là không đủ để đảm bảo chiếc xe hoạt động tốt. Bạn cần kiểm tra bộ khởi động, pin, máy phát điện, chìa khóa, công tắc đánh lửa --- và danh sách sẽ tiếp tục --- chỉ để vào xe và khởi động nó. Mỗi thành phần cần kiểm tra riêng của họ.

Kịch bản trên là một bài kiểm tra "Bức tranh lớn". Mỗi thành phần của chiếc xe cần có các bài kiểm tra "Hình ảnh nhỏ" để đảm bảo chúng hoạt động chính xác trong toàn bộ.

Xây dựng và kiểm thử phần mềm là giống nhau ở nhiều khía cạnh. Bạn thiết kế từ trên xuống, sau đó xây dựng từ dưới lên. Tại sao có một cánh cửa nâng lên nếu bạn thậm chí không thể khởi động động cơ? Tại sao có một bộ khởi động nếu bạn không có pin?

Nhóm sản phẩm của bạn sẽ đưa ra các Thử nghiệm chấp nhận và xác nhận chúng trong Cucumber. Điều này cung cấp cho bạn "Bức tranh lớn". Bây giờ, nhóm kỹ sư sẽ thiết kế các thành phần phù hợp và cách chúng tương tác, sau đó kiểm tra từng bộ phận riêng biệt --- đây là các Bài kiểm tra đơn vị của bạn.

Khi Bài kiểm tra đơn vị được thông qua, hãy bắt đầu thực hiện các kịch bản Cucumber. Khi những thứ đó trôi qua, bạn đã cung cấp những gì nhóm sản phẩm đã yêu cầu.

Tôi đang cố gắng để hiểu BDD. Tôi đã đọc một số bài báo và theo tôi hiểu thì BDD là "bước tiếp theo" từ TDD. Tôi nói điều đó bởi vì tôi thấy cả hai đều rất giống nhau và như tôi có thể đọc trong bài viết này, BDD được sinh ra như một sự cải tiến từ TDD.

Trên thực tế, không, BDD không phải là "bước tiếp theo" từ TDD. Đó là TDD. Hay chính xác hơn, đó là một sự chia sẻ lại của TDD.

Những người tạo ra BDD nhận thấy rằng trở ngại lớn để hiểu rằng TDD không phải là về thử nghiệm mà là về đặc tả hành vi là tất cả các thuật ngữ TDD là về thử nghiệm chứ không phải về đặc tả hành vi. Nó giống như cố gắng không nghĩ về một con voi màu hồng khi ai đó nói với bạn "cố gắng không nghĩ về một con voi màu hồng", ngoại trừ sự phức tạp thêm khi ở trong một căn phòng đầy những con voi màu hồng và một chàng trai liên tục hét lên "voi hồng, hồng voi, voi hồng "trong tai bạn.

Vì vậy, họ đã đánh giá lại TDD về đặc điểm kỹ thuật hành vi. "Thử nghiệm" và "trường hợp thử nghiệm" hiện là "ví dụ", "đơn vị" là "hành vi", "khẳng định" là "kỳ vọng", v.v.

Tuy nhiên, phương pháp vẫn giống nhau. Bạn bắt đầu với một bài kiểm tra chấp nhận (ý tôi là "tính năng"), phóng to bài kiểm tra đơn vị (ý tôi là "ví dụ"), thu nhỏ lại, v.v.

Tôi muốn có bài kiểm tra đơn vị. Làm cách nào để kiểm tra mã kiểm tra xem bộ phân phối có tiền không? Hoặc là tiền mặt được phân phối? Hoặc tài khoản bị ghi nợ khi được yêu cầu? Làm cách nào tôi có thể kết hợp các bài kiểm tra đơn vị với các bài kiểm tra "BA Tạo"?

Giống như cách bạn làm trong TDD. Bạn có thể viết các tính năng và ví dụ của mình trong các khung khác nhau (ví dụ: Cucumber và RSpec) hoặc thậm chí các ngôn ngữ khác nhau (ví dụ: viết ví dụ cho dự án C bằng C và các tính năng trong FIT / Fitnesse), bạn có thể sử dụng một khung tính năng duy nhất cho cả hai ( ví dụ viết các ví dụ và tính năng trong Cucumber) hoặc bạn có thể sử dụng khung ví dụ đơn cho cả hai (ví dụ: viết cả trong RSpec). Bạn thậm chí không phải sử dụng một khuôn khổ nào cả.

Một ví dụ về TDD-doing-right (giống hệt với BDD) chỉ sử dụng một khung duy nhất là chính JUnit, chứa hỗn hợp các bài kiểm tra đơn vị (ví dụ) và kiểm tra chức năng / tích hợp (tính năng), tất cả được viết bằng chính JUnit.

Tôi tin rằng Kent Beck gọi đây là "phóng to". Bắt đầu cấp cao, sau đó "phóng to" đến các chi tiết, sau đó quay lại.

Tuyên bố miễn trừ trách nhiệm: Tôi không phải là chuyên gia về BDD, nhưng tôi cố gắng cung cấp cho bạn quan điểm của tôi về bài viết mà bạn liên kết đến.

TDD là một kỹ thuật triển khai - trước tiên bạn viết một bài kiểm tra, sau đó bạn thực hiện phương thức, chạy thử nghiệm, cấu trúc lại và thêm các bài kiểm tra khác cho cùng một phương thức hoặc cho một phương thức mới. TDD thực sự không định nghĩa bất kỳ quy tắc nào về cách chọn tên lớp hoặc tên phương thức, tùy thuộc vào bạn. TDD cũng không cho bạn biết "khi nào bạn hoàn thành".

Vì vậy, bất cứ khi nào bạn viết một bài kiểm tra cho một phương thức mới, bạn phải chọn một tên phương thức - và đó là điểm mà BDD xuất hiện. Bằng cách chọn tên phương thức sử dụng các thuật ngữ kinh doanh từ kịch bản trên và bằng cách chọn chúng theo cách mô tả hành vi của lớp bạn, bạn đang làm BDD. Bất cứ khi nào bạn tự hỏi mình "tôi có phải thêm các bài kiểm tra nữa không", bạn có thể xem các tình huống do BA của bạn đưa ra và kiểm tra xem bạn đã thực hiện hoàn toàn tất cả các phần cần thiết chưa. Nếu không, bạn sẽ cần thêm nhiều bài kiểm tra.

Tác giả của bài viết cũng đề nghị sử dụng sơ đồ đặt tên liên quan đến hành vi hơn khi chọn tên các bài kiểm tra của bạn, đó là lý do tại sao anh ấy đề nghị thay thế JUnit bằng một công cụ không dựa trên sơ đồ đặt tên mà mỗi trường hợp kiểm tra phải bắt đầu tên "kiểm tra". Mặc dù tôi không biết JBehave, tôi nghĩ đó là điểm khác biệt chính giữa công cụ đó và Junit.

Ngoài ra, các kịch bản BDD cũng sẽ là một kế hoạch chi tiết cho các thử nghiệm tích hợp - mà bạn thường sẽ thêm sau khi bạn xác định tên phương thức bằng TDD và sau khi bạn thêm một lượng thử nghiệm đơn vị hợp lý.

Vì vậy, theo hiểu biết của tôi, TDD là một công cụ bạn có thể sử dụng như một phần của BDD và BDD giúp bạn viết các bài kiểm tra đúng và đặt cho chúng tên tốt hơn.