Là BDD có thể mở rộng cho các dự án vừa và lớn?

Trong mỗi trang web bạn đọc về BDD (Phát triển hướng hành vi), bạn tìm thấy một ví dụ rất đơn giản cho bạn thấy nó rõ ràng và dễ dàng như thế nào để xác định các yêu cầu của bạn. Nhưng cố gắng thực hiện quy trình này trong một sản phẩm lớn (không phải là ví dụ máy tính) cho tôi thấy rằng mọi thứ có thể nhận được (hoặc sẽ nhận được) khá phức tạp và không thể đọc được; đặc biệt là thay đổi các yêu cầu tại một thời điểm sau đó có nghĩa là rất nhiều công việc để sửa các bài kiểm tra Tích hợp cho việc này.

Vì vậy, tôi tự hỏi, liệu BDD có thực sự xứng đáng? Liệu nó có giải quyết được một vấn đề mà các kỹ thuật khác không làm được!

Tôi nghĩ rằng một trong những tài nguyên tốt nhất trên BDD là Đặc tả theo sách Ví dụ . Nó nói rất nhiều về cách tổ chức các bài kiểm tra BDD và cách viết chúng để chúng không gây ra quá nhiều việc làm khi yêu cầu thay đổi.

Nếu mọi thứ trở nên phức tạp hoặc quá phức tạp trong các bài kiểm tra của bạn thì có lẽ bạn đang làm sai điều gì đó. Nó giống với BDD và TDD. Viết bài kiểm tra tốt là khó và phải mất nhiều tháng để học nó.

Nó có thể giúp nhận ra rằng trọng tâm của BDD là các cuộc hội thoại . BDD thực sự là một công cụ phân tích tình cờ cung cấp một số thử nghiệm hồi quy như một sản phẩm phụ đẹp.

Tôi đã sử dụng các kịch bản ở tất cả các cấp độ trong cuộc trò chuyện; từ việc xác định các bên liên quan khác nhau để xem liệu một bản phát hành có khả năng được đón nhận hay không, đến tìm hiểu cách thức hoạt động của một mô-đun hoặc lớp .

Có một vài gợi ý và lời khuyên tôi có thể đề xuất để làm cho việc này dễ dàng hơn.

Nếu bạn chưa bao giờ làm điều đó trước đây, nó sẽ thay đổi.

Bất cứ điều gì mới đối với tên miền hoặc doanh nghiệp đều có thể thay đổi. Bạn có thể nhận ra bạn đang ở trong không gian này nếu bạn đang nói chuyện qua các tình huống, đặt câu hỏi cho họ và doanh nghiệp nói, "Ồ, tôi không chắc chắn." Đó là một dấu hiệu tốt để ngừng cố gắng thực hiện BDD và tăng cường một cái gì đó để có được phản hồi nhanh hơn, để giúp doanh nghiệp tìm ra những gì họ muốn. Khi các ý tưởng đã ổn định, các kịch bản có thể được viết lại.

Tất cả các dự án đều có một số khía cạnh đối với chúng là mới, hoặc bạn sẽ không thực hiện chúng.

Nếu bạn đã làm nó trước đây, nó nhàm chán.

Cũng như các khía cạnh mới, khác biệt , các dự án thường có một số khía cạnh được thương mại hóa tương tự như các khía cạnh đã được thực hiện. Chẳng hạn, nếu tôi đang sản xuất một chiếc điện thoại di động mới, nó vẫn cần phải thực hiện cuộc gọi. "Gọi điện thoại" là một kịch bản nổi tiếng đến mức chúng ta không cần phải nói qua nó. Tương tự, những thứ như "đăng nhập" hoặc thậm chí "đăng ký người dùng" thật nhàm chán.

Bất cứ nơi nào có thể, hãy sử dụng các thư viện cho những thứ này, và sau đó bạn sẽ không phải viết các kịch bản xung quanh chúng. Ngoài ra, hãy thực hiện các bit khác trước - có người dùng đã đăng nhập và tìm hiểu xem anh ấy đang đăng nhập vào mục nào . Những khu vực này không có khả năng thay đổi, vì vậy dù sao bạn cũng có thể thoát khỏi việc kiểm tra thủ công.

Nếu ai đó đã làm điều đó trước đây, nói chuyện thông qua các kịch bản có thể giúp đỡ.

Có một chút giữa nơi chúng ta có các yêu cầu cụ thể về tên miền, những thứ tương đối dễ hiểu bởi ai đó và sự không chắc chắn thực sự chủ yếu xoay quanh phạm vi thay vì hành vi thực tế của hệ thống.

Nói chuyện qua các kịch bản có thể giúp nhóm phát triển khám phá hành vi, rút ​​ra kiến ​​thức của một chuyên gia và để đảm bảo rằng hành vi có giá trị đã biết được nắm bắt.

Đây là bit mà BDD hoạt động tốt nhất. Mẹo của tôi là viết các kịch bản thú vị nhất ở đầu tệp tính năng (hoặc wiki, nếu bạn không tự động hóa) và xóa mọi kịch bản trùng lặp hoặc dễ suy ra.

Bất cứ nơi nào có thể, hãy sử dụng các kịch bản giống như các ví dụ về cách ứng dụng hoạt động . Ví dụ: nếu bạn muốn hiển thị cách xác thực hoạt động, hãy hiển thị một vài ví dụ về cách ứng dụng giúp người dùng điền vào biểu mẫu. Kiểm tra xác nhận là nghiêm ngặt bằng cách sử dụng thử nghiệm đơn vị, dễ dàng hơn nhiều để duy trì và chạy nhanh hơn.

đọc thêm

Nếu bạn quan tâm đến điều này, đây là một số điều tôi đã viết có thể giúp ích.

BDD trong lớn

Cynefin cho nhà phát triển , đi sâu vào ba lĩnh vực này chi tiết hơn

Các slide hướng dẫn của tôi , tất cả đều đẹp và được chú thích cho bạn, và bao gồm cả stack.

Chúng tôi đã xây dựng một dự án khá phức tạp ( độ phức tạp miền ) vào mùa thu năm ngoái và tôi có thể thành thật nói rằng việc đưa công việc phía trước vào BDD đã cứu dự án. Tôi đã thấy một mối tương quan mạnh mẽ giữa độ phức tạp của miền và lợi ích của BDD.

Hãy để tôi có một điều ngoài lề: kiểm tra các quy tắc kinh doanh phức tạp là khó khăn. Câu hỏi là, bạn có muốn thử và nhớ tất cả các kịch bản điên rồ bất cứ khi nào bạn thực hiện thay đổi hoặc bạn muốn mạng lưới an toàn đó cho bạn biết khi bạn phá vỡ thông số kỹ thuật. Dành thời gian trước và tìm ra tất cả các kịch bản, viết chúng ra và cuối cùng viết tất cả các bài kiểm tra cho chúng.

Và khi bạn quay lại sau để cố gắng hiểu mọi thứ, có thông số kỹ thuật có thể kiểm chứng đó là một sự cứu rỗi.

BDD là một quá trình phát triển dựa trên TDD (Phát triển dựa trên thử nghiệm) Dưới đây là một số ưu và nhược điểm của TDD được rút ra từ kinh nghiệm cá nhân của tôi:

• TDD, đảm bảo rằng phạm vi của bạn được xác định rõ. Bằng cách này, bạn thiết kế trường hợp thử nghiệm của bạn đầu tiên. Do đó, đặt kỳ vọng cho đoạn mã bạn phải viết.
• TDD là một cách bảo vệ mã của bạn. Giả sử bạn viết một hàm đơn giản và sau đó bạn thêm một số điều kiện chuyển đổi phức tạp trong cùng hàm này. Ngày mai, nếu người khác muốn sửa đổi chức năng này, anh ta có thể tham khảo trường hợp thử nghiệm. Nếu anh ta muốn thay đổi chức năng của bạn, thì anh ta cũng phải thay đổi trường hợp kiểm tra (hầu hết các lần). Điều này cho phép anh ấy / cô ấy hiểu rằng có một lý do đằng sau những gì bạn đã viết.
• TDD cho phép phát triển phần mềm nhanh hơn. Mỗi người trong chúng ta sẽ phải đối mặt với vấn đề này trong khi viết mã. Chúng tôi bắt đầu với một ý tưởng. Và dần dần mất dấu vết của nó. Chúng tôi cuối cùng đặt các đoạn mã không mong muốn để xử lý một số tình huống. Trong TDD, bạn đặt kỳ vọng trả trước. Qua đó, bạn hạn chế bản thân đi lang thang quá xa mục tiêu.
• TDD cho phép bạn bắt các lỗi có thể xảy ra trước khi dự án lên mạng. Điều này chủ yếu phải làm với chất lượng của các trường hợp thử nghiệm được viết.

Nhược điểm:

• Lúc đầu, TDD có thể là một chút khó khăn. Nhiều người không hiểu khái niệm phát triển lái xe trường hợp thử nghiệm.
• TDD, đôi khi có thể dẫn đến những nỗ lực lớn trong bảo trì. Điều này có liên quan đến các trường hợp thử nghiệm không mong muốn hoặc vô nghĩa.
• TDD phải được thực hiện với một nhúm muối. Không có nhà phát triển nào thích dành thời gian cho một số trường hợp thử nghiệm được viết bởi người khác. Giải mã ý nghĩa của testcase đôi khi có thể gây ra đau đầu lớn.

Tôi làm việc trong một dự án với hơn 900.000 dòng mã. Và tôi vẫn theo dõi BDD. Một điều quan trọng bạn cần xem xét là số lỗi có thể xảy ra hoàn toàn do các trường hợp kiểm tra. Vài năm sau, bạn sẽ bị BDD chửi thề!