BDD có phải là sự thay thế TDD không?

Question

Tôi tự hỏi liệu BDD có thay thế là TDD không? Những gì tôi hiểu bây giờ là ở một BDD cuối cùng, chúng tôi không có kiểm tra đơn vị nữa. Thay vào đó có những câu chuyện/kịch bản/tính năng và "bước thử nghiệm". Và nó trông giống như một sự thay thế hoàn toàn của TDD cho tôi. TDD đã chết?

Answer 1

Không hề. BDD chỉ là một biến thể của TDD.

Trong TDD, bạn xây dựng các yêu cầu của bạn như là một thử nghiệm thực thi, sau đó viết mã sản xuất để thực hiện kiểm tra. BDD không làm gì ngoài việc xây dựng lại các yêu cầu này thành một dạng dễ đọc hơn và do đó làm cho các bài kiểm tra có phần chi tiết hơn đối với một người đọc, những người xem xét báo cáo thử nghiệm. (Btw: Để đạt được điều này, BDD yêu cầu mã nhiều hơn so với thử nghiệm đơn vị truyền dữ liệu truyền thống ...)

Đó là tất cả.

Thomas

Answer 2

Tôi có quan điểm khác về vấn đề này so với những người phản hồi khác.

Dan North đã tạo BDD cho công việc tư vấn của mình về TDD khi ông thấy, nhiều người bị nhầm lẫn bởi phần "kiểm tra", vì họ có kinh nghiệm kiểm tra, ông quyết định đổi tên. Vì vậy, lúc đầu, BDD chính xác là TDD, được giải thích một cách chính xác. Sau đó, Dan bắt đầu mở rộng ý tưởng về việc sử dụng các đặc tả thực thi (các kiểm tra đơn vị) để thúc đẩy việc triển khai bằng cách thêm các mức đặc tả khác. Ông được lấy cảm hứng từ những câu chuyện của người dùng, vì vậy BDD đơn giản nhất được thực hiện bởi hầu hết các công cụ cho phép bạn viết các yêu cầu như kịch bản câu chuyện của người dùng, hơn là bạn viết mã để tạo ra các bài kiểm tra đơn vị và hơn các bài kiểm tra đơn vị mà bạn thực hiện. Vì vậy, bây giờ bạn thấy so với TDD có một mức độ đặc điểm kỹ thuật - câu chuyện của người dùng. Nhiều công cụ bao gồm dịch các câu chuyện của người dùng để kiểm tra, nên nhiều người quên chúng như bạn đã làm, nhưng chúng vẫn ở đó và không thể bỏ qua hoàn toàn - thực tế và về mặt lý thuyết như đã lưu ý, câu chuyện người dùng lập trình không hiệu quả. Nhưng đó không phải là vấn đề, bạn sử dụng các câu chuyện của người dùng để thu thập các yêu cầu từ các bên liên quan và để thúc đẩy bạn triển khai chúng bằng cách thực hiện các bài kiểm tra chấp nhận.

Có nhiều thứ nhỏ khác trong BDD, bạn nên đọc blog Dans để hiểu chúng, nhưng điểm chính là BDD là phần mở rộng của TDD ngay cả ngoài giai đoạn thực hiện, vì vậy chúng không thể thay đổi hoặc hiển thị khác.

Answer 3

Gabriel gần như đúng.

Sự khác biệt cơ bản ở cấp đơn vị là BDD sử dụng từ "nên" thay vì "kiểm tra". Nó chỉ ra rằng khi bạn nói "thử nghiệm", hầu hết mọi người bắt đầu suy nghĩ về những gì mã của họ làm, và làm thế nào họ có thể kiểm tra nó. Với BDD, chúng tôi xem xét - và câu hỏi - mã của chúng tôi nên làm gì. Đó là một điểm quan trọng nhưng quan trọng, và nếu bạn muốn biết tại sao nó lại mạnh mẽ, hãy đọc lên chương trình ngôn ngữ thần kinh - đặc biệt là xung quanh cách mà từ đó ảnh hưởng đến suy nghĩ và mô hình của thế giới. Như một ví dụ ngắn gọn, nhiều người mới sử dụng TDD bắt đầu ghim mã của họ xuống để không ai có thể phá vỡ nó. BDDers có xu hướng cung cấp các ví dụ minh họa giá trị mã của chúng để mọi người có thể thay đổi mã của họ một cách an toàn.

Dan nhận ra khi anh ấy đang nói chuyện với Chris Matts và viết JBehave rằng anh ấy có thể thực hiện việc này lên cấp độ kịch bản (kịch bản không hoàn toàn giống với câu chuyện). Bởi vì chúng tôi đã sử dụng "nên" ở một cấp độ đơn vị, nó có ý nghĩa để bắt đầu viết những thứ bằng tiếng Anh (tôi có xu hướng sử dụng "nên cho tôi" hơn là "nên trở về", ví dụ). Chấp nhận thử nghiệm phát triển theo định hướng - ATDD - đã tồn tại từ rất lâu, nhưng đây là lần đầu tiên AFAIK viết bất kỳ ai bằng tiếng Anh với các bên liên quan kinh doanh.

Nó không chỉ thay thế cho TDD. Đó là một cách suy nghĩ khác về thử nghiệm - tập trung nhiều vào việc học, cố ý khám phá những khu vực mà chúng ta có thể nghĩ chúng ta biết mình đang làm gì nhưng không phát hiện và giúp chúng ta giải quyết sự thiếu hiểu biết và hiểu lầm. Nó hoạt động ở nhiều cấp độ. Tính năng tiêm của Chris Matts đưa nó vào không gian cấp cao hơn, đúng cách để dự đoán tầm nhìn.

Chúng tôi vẫn viết các ví dụ - hoặc thông số kỹ thuật nếu bạn thích - ở cấp độ đơn vị, nhưng thực sự, đó là một mô hình cao hơn nhiều so với các kịch bản. Nếu bạn muốn biết thêm bạn might find my blog useful, Dan's is even better. Ngoài ra, Chris has a comic book on Real Options mô tả một số mẫu mà tôi đã đề cập.

Answer 4

BDD không phải là thay thế TDD. Đó là về việc đưa ra một số cấu trúc và deciplene hơn để thực hành TDD của bạn. Điều khó khăn nhất về TDD là các nhà phát triển không có hình ảnh lớn hơn hầu như không có manh mối về những gì cần kiểm tra và bao nhiêu để kiểm tra. BDD cung cấp một hướng dẫn rất cụ thể với khu vực màu xám này. Kiểm tra bài viết này,

http://codingcraft.wordpress.com/2011/11/12/bdd-get-your-tdd-right/

Answer 5

Theo như tôi hiểu những ưu điểm của BDD qua TDD là:

• Cách ly các bài kiểm tra từ các chi tiết thực hiện. Vì vậy, các tệp tính năng sẽ không bị hỏng, chỉ các tệp bước, nếu bạn sửa đổi triển khai, nhưng không phải là hành vi.
• Sử dụng lại mã kiểm tra hiện tại. Bạn có thể làm tương tự bằng TDD, nếu bạn xác định các xác nhận tùy chỉnh, đồ đạc, người trợ giúp, v.v ... Nhưng chúng tôi (ít nhất là tôi) thường sao chép mã dán thử nghiệm (thói quen xấu). Việc sử dụng lại mã theo BDD dễ dàng hơn nhiều. Sẽ vẫn còn một số sự lặp lại, nhưng ít nhất nó sẽ có trong gherkin.

Mọi thứ khác giống như cách thông thường của TDD. Vì vậy, bạn có thể sử dụng bất kỳ lib khẳng định nào trong các định nghĩa bước mà bạn sẽ sử dụng trong các bài kiểm tra đơn vị. Sự khác biệt duy nhất mà bạn đã thêm một mức trừu tượng khác bằng cách tách những gì (mô tả tính năng trong gherkin) từ cách thức (các định nghĩa bước trong một ngôn ngữ lập trình) trong mã thử nghiệm của bạn.

Answer 6

Bạn có thể sử dụng cụm từ "Specification by Example" cho BDD, nhấn mạnh một khía cạnh quan trọng của phương pháp này: Chỉ định cộng tác - thông qua các hội thảo đặc điểm toàn đội, cuộc họp nhỏ hoặc đánh giá qua điện thoại. Trong các phiên họp này với các bên liên quan khác nhau, các ví dụ cụ thể được sử dụng để minh họa các yêu cầu. Việc thảo luận các yêu cầu dưới dạng ví dụ giúp tạo ra sự hiểu biết chung về miền vấn đề và các giải pháp có thể có.

Thông số kỹ thuật tai nạn với các ví dụ rất thích hợp cho tự động hóa thử nghiệm. Kết quả là bạn thường cải thiện phạm vi kiểm tra. Nhưng phương pháp này cũng giúp involve non-technical stakeholders. Các công cụ giúp bạn create business readable input là bản chất không liên quan đến ngôn ngữ lập trình, nhưng thường dựa trên simple document formats mà nhiều người có thể dễ dàng hiểu được.

Answer 7

BDD nên nhấn mạnh hành vi từ góc độ người dùng và lý tưởng để điều khiển các thử nghiệm từ đầu đến cuối, một loại DSL của người nghèo để phát triển thử nghiệm chấp nhận. Nó có thể bổ sung cho TDD nhưng chắc chắn nó không phải là một thay thế. TDD có nhiều hoạt động thiết kế vì nó là một hoạt động thử nghiệm (Mã được thiết kế kém khó kiểm tra -> kiểm tra đơn vị khuyến khích thiết kế tốt). BDD không liên quan gì đến thiết kế. Đó là một loại thử nghiệm tóm tắt hoàn toàn khỏi mã.Trong thực tế, kết quả BDD có nhiều mã tấm nồi hơi hơn mũ kiểm tra chấp nhận thông thường, do đó tôi thích tạo một DSL nội bộ bằng ngôn ngữ lập trình thông thường để thúc đẩy các bài kiểm tra chấp nhận của tôi. Đối với các thử nghiệm đơn vị, BDD nhấn mạnh hành vi từ góc độ người dùng và do đó không nên được sử dụng ở cấp đơn vị.

BDD là nỗ lực thu hẹp khoảng cách giao tiếp giữa các chủ sở hữu và lập trình viên kinh doanh. Ở một số khu vực, nó có thể hữu ích, chẳng hạn như các ứng dụng ngân hàng, nơi chú ý đến chi tiết về những thứ như tính toán lãi suất là quan trọng và yêu cầu đầu vào trực tiếp từ các chuyên gia miền. IMHO BDD không phải là thuốc chữa bách bệnh mà một số acolytes của nó tuyên bố nó là và chỉ nên được sử dụng nếu có một lý do thuyết phục để làm như vậy.