Mối quan hệ giữa BDD và TDD

Mối quan hệ của BDD và TDD là gì?

Từ những gì tôi hiểu, BDD bổ sung hai điều chính qua TDD: kiểm tra đặt tên (đảm bảo / nên) và kiểm tra chấp nhận. Tôi có nên theo TDD trong quá trình phát triển bởi BDD không? Nếu có, các bài kiểm tra đơn vị TDD của tôi có nên được đặt tên theo cùng một kiểu đảm bảo / nên không?

BDD thêm một chu kỳ xung quanh chu trình TDD.

Vì vậy, bạn bắt đầu với một hành vi và để điều đó thúc đẩy các bài kiểm tra của bạn, sau đó để các bài kiểm tra thúc đẩy sự phát triển. Lý tưởng nhất là BDD được điều khiển bởi một số loại thử nghiệm chấp nhận, nhưng điều đó không cần thiết 100%. Miễn là bạn có hành vi dự kiến ​​được xác định, bạn sẽ ổn.

Vì vậy, giả sử bạn đang viết Trang đăng nhập.

Bắt đầu với con đường hạnh phúc:

Given that I am on the login page
When I enter valid details
Then I should be logged into the site
And shown my default page

Cú pháp Cho-Và-Khi-Và-Rồi-Và này là phổ biến trong phát triển theo hành vi. Một trong những lợi thế của nó là nó có thể được đọc (và, được đào tạo, viết) bởi những người không phải là nhà phát triển - nghĩa là, các bên liên quan của bạn có thể xem danh sách các hành vi bạn đã xác định để hoàn thành thành công nhiệm vụ và xem liệu nó có phù hợp với mong đợi của họ từ lâu trước khi bạn phát hành một sản phẩm không hoàn chỉnh.

Có một ngôn ngữ kịch bản, được gọi là Gherkin, trông rất giống với ngôn ngữ trên và cho phép bạn viết mã kiểm tra đằng sau các mệnh đề trong các hành vi này. Bạn nên tìm kiếm một dịch giả dựa trên Gherkin cho khung phát triển thông thường của bạn. Đó là ngoài phạm vi của câu trả lời này.

Dù sao, trở lại hành vi. Ứng dụng hiện tại của bạn chưa làm điều này (nếu có thì tại sao có ai đó yêu cầu thay đổi?), Vì vậy bạn đang thất bại trong bài kiểm tra này, cho dù bạn đang sử dụng trình chạy thử nghiệm hay chỉ đơn giản là kiểm tra thủ công.

Vì vậy, bây giờ đã đến lúc chuyển sang chu trình TDD để cung cấp chức năng đó.

Cho dù bạn có viết BDD hay không, các bài kiểm tra của bạn nên được đặt tên theo một cú pháp chung. Một trong những phổ biến nhất là cú pháp "nên" mà bạn mô tả.

Viết một bài kiểm tra: ShouldAcceptValidDetails. Trải qua chu trình Red-Green-Refactor cho đến khi bạn hài lòng với nó. Bây giờ chúng ta có vượt qua bài kiểm tra hành vi không? Nếu không, hãy viết một bài kiểm tra khác: ShouldRedirectToUserDefaultPage. Red-Green-Refactor cho đến khi bạn hạnh phúc. Rửa, rửa, lặp lại cho đến khi bạn hoàn thành các tiêu chí được quy định trong hành vi.

Và sau đó chúng ta chuyển sang hành vi tiếp theo.

Given that I am on the login page
When I enter an incorrect password
Then I should be returned to the login page
And shown the error "Incorrect Password"

Bây giờ bạn không nên tránh điều này để vượt qua hành vi trước đó của bạn. Bạn nên trượt bài kiểm tra này vào thời điểm này. Vì vậy, thả trở lại chu kỳ TDD của bạn.

Và như vậy cho đến khi bạn có trang của bạn.

Rất khuyến khích Sách Rspec để tìm hiểu thêm về BDD và TDD, ngay cả khi bạn không phải là nhà phát triển Ruby.

Hiểu biết của tôi về nó:

• BDD bắt đầu như là một thương hiệu của TDD để tập trung vào hành vi rõ ràng hơn.
• Nó cung cấp hỗ trợ chính thức hơn (DSL và công cụ) để tập trung vào hành vi và thông số kỹ thuật thực thi.
• Bây giờ BDD có thể được xem như là một siêu khối của TDD ,. Nó đã phát triển theo thời gian để bao gồm nhiều hơn các khía cạnh khơi gợi yêu cầu, nhưng vẫn là phía quá trình phát triển là một phần cốt lõi của nó.

Vì vậy, để giải quyết TDD được thực hiện đúng phần của BDD. BDD bắt đầu như một sự thay đổi trong ngôn ngữ của TDD để làm cho ý định của quá trình rõ ràng. Bài viết giới thiệu của Dan North về BDD giải thích tại sao tập trung vào hành vi từ hơn là kiểm tra là hữu ích - nó giúp xác nhận rằng bạn không chỉ xây dựng phần mềm đúng, bạn cũng đang xây dựng phần mềm phù hợp. Đây luôn là một phần của cách tiếp cận TDD tốt, nhưng Dan đã mã hóa nó một chút thành BDD.

Điều tôi nghĩ rằng BDD làm cho rõ ràng hơn một chút so với TDD, hoặc ít nhất là chính thức hóa và cung cấp hỗ trợ công cụ cho, là cách tiếp cận phóng to / thu nhỏ hai vòng / phóng to hai vòng / thu nhỏ này. Trước tiên, bạn mô tả hành vi dự kiến ​​của tính năng (vòng lặp bên ngoài), sau đó phóng to vào vòng lặp bên trong để xử lý các thông số kỹ thuật cấp thấp.

Từ http://www.metesreau.com/ncraft-workshop/

Gherkin kết hợp với các công cụ như Cucumber và SpecFlow cung cấp cách viết các đặc tả tính năng cấp cao đó và sau đó liên kết chúng với mã thực thi mã ứng dụng. Tôi sẽ lập luận rằng đây là nơi mà BDD có thể 'cảm thấy' khác với TDD, nhưng nó thực sự vẫn đang làm điều tương tự, chỉ với một số hỗ trợ công cụ bổ sung và DSL. Gần hơn với TDD 'truyền thống' đang sử dụng các công cụ như rspec, nspec, spock. Những người này cảm thấy giống một quá trình giống như bạn làm trong TDD 'truyền thống' nhưng với ngôn ngữ tập trung vào hành vi nhiều hơn.

Trong BDD in Action của John Ferguson Smart (rất được khuyến khích), ông ủng hộ cách tiếp cận vòng lặp kép, bắt đầu với một cái gì đó như jBehave ở các thông số kỹ thuật thực thi cấp độ bên ngoài, sau đó thả vào một công cụ như Spock cho các thông số kỹ thuật cấp thấp.

BDD đưa khái niệm về hướng kiểm tra đến gần hơn với các bên liên quan kinh doanh. Gherkin được thiết kế để doanh nghiệp có thể đọc được và ý tưởng về 'tài liệu sống', tức là tự động tạo báo cáo tiến độ từ thông số kỹ thuật thực thi của bạn là về việc đưa ra phản hồi cho các bên liên quan.

Một phần khác của BDD bây giờ, đó là nơi nó thực sự trở thành thứ gì đó kết hợp TDD như một phần của một quy trình lớn hơn, là các bit và phần gợi ra yêu cầu. Các ý tưởng như Tính năng tiêm, Lập bản đồ tác động và Tùy chọn thực là một phần của bên này.

Đối với câu trả lời kinh điển về điều này, tốt nhất nên đến Dan North một lần nữa . Nếu nhóm của bạn là tất cả các nhà phát triển, thì BDD = TDD. Nếu nhóm của bạn liên quan đến toàn bộ các bên liên quan, thì BDD gần với XP hơn, với TDD là một phần của nó.

Mối quan hệ của BDD và TDD là gì?

Họ là những điều tương tự.

Từ những gì tôi hiểu, BDD bổ sung hai điều chính qua TDD: kiểm tra việc đặt tên (đảm bảo / nên)

Đó thực sự không phải là thứ mà BDD "thêm". Đó chỉ là một quy ước khác nhau nhằm giúp cho việc dạy và hiểu TDD dễ dàng hơn.

Những người tạo ra BDD đều dạy TDD và họ nhận thấy rằng điều khó hiểu nhất là TDD hoàn toàn không liên quan gì đến việc kiểm tra. Một khi học sinh vượt qua rào cản đó, nó sẽ dễ dàng hơn nhiều đối với họ. Nhưng, thật khó để tự ly dị với suy nghĩ về kiểm tra , khi từ "kiểm tra" (hoặc thuật ngữ liên quan như "khẳng định") thực tế xuất hiện ở mọi nơi . Vì vậy, họ chuyển một số từ xung quanh.

Nhưng đó chỉ là lời nói! Không có sự khác biệt thực tế giữa TDD và BDD.

và kiểm tra chấp nhận.

Các xét nghiệm chấp nhận cũng là một phần quan trọng của TDD giống như chúng là của BDD. Xin nhắc lại: không có sự khác biệt giữa TDD và BDD: TDD được thực hiện đúng là BDD, BDD là TDD được thực hiện đúng.