Từ câu chuyện, tôi suy luận rằng bạn đang tự mình viết mã.
Thông thường, mục đích của BDD là cho phép các cuộc hội thoại, đặc biệt là giữa doanh nghiệp và nhà phát triển, để nhóm có thể chắc chắn rằng họ đã đạt được sự hiểu biết chung. Chúng tôi cũng muốn bao gồm những người thử nghiệm, bởi vì họ có thể phát hiện ra khi chúng tôi bỏ lỡ các tình huống.
Nếu bạn đang tự làm việc này, hãy lấy một con vịt cao su và giải thích hành vi của ứng dụng của bạn với con vịt. Cho một số ví dụ về cách nó nên hoạt động. Đó sẽ là những kịch bản của bạn.
Để bắt đầu, tôi sẽ đề nghị không tự động hóa các kịch bản đó. Bạn có thể viết chúng ra nếu bạn thích. Hãy nhớ rằng kết quả kinh doanh mà bạn đã chia sẻ với con vịt là về mức độ phù hợp để diễn đạt chúng. Bây giờ bạn sẽ có ý tưởng về cách ứng dụng hoạt động và bạn có thể chạy qua các tình huống theo cách thủ công. Tôi thích đối xử với mọi thứ không hoạt động như một lỗi . Đôi khi tôi đã bắt đầu với tự động hóa, nhưng chỉ khi tôi biết rất rõ hệ thống hoạt động như thế nào, tôi mới quen với các công cụ và giao diện người dùng được hiểu rõ. Thậm chí sau đó tôi thường phải làm lại nó một chút khi tôi đã viết mã.
Ở cấp độ thấp hơn, hãy nói với con vịt của bạn cách mỗi lớp sẽ cư xử. Cung cấp một số ví dụ. Vịt cao su hoàn toàn có khả năng hiểu ngôn ngữ kỹ thuật. Bây giờ bạn có BDD cấp đơn vị, còn gọi là kiểm tra đơn vị. Chu kỳ tái cấu trúc đỏ-xanh xảy ra ở đây. (Tôi không có xu hướng cần phải cấu trúc lại nhiều nữa, bởi vì tôi đang nghĩ về trách nhiệm của các lớp học, diễn đạt nó theo ngôn ngữ định hướng kinh doanh và dù sao nó cũng có xu hướng rơi ra một cách khá hay. Nhưng tôi Tôi đã làm điều này được một lúc rồi. Sẽ ổn thôi nếu bạn làm thế.)
Đừng tái cấu trúc nó quá nhiều. Chúng tôi vẫn muốn nhận phản hồi về mã của mình, vì luôn có những điều chúng tôi không biết mà chúng tôi không biết . Sự hoàn hảo là kẻ thù của bạn ở đây. Làm cho nó đủ tốt, làm cho nó dễ đọc, sau đó tiếp tục. Nếu bạn cần làm cho một cái gì đó hoàn hảo để thực hiện các thay đổi hơn nữa, hãy làm điều đó khi bạn thực hiện các thay đổi tiếp theo.
Nếu bạn có cơ hội nhận phản hồi về các kịch bản của mình từ các bên liên quan trong kinh doanh, nhưng họ không ngồi cùng bạn, bạn có thể gửi các kịch bản cho họ ngay khi bạn viết và trước khi bạn tự động hóa chúng. Bạn cũng có thể muốn gửi một bản mô phỏng UI, để chúng có thể tương quan các từ với hành động. Đừng đi quá xa trước mã hóa với điều này. Làm việc với giả định rằng những gì bạn đã làm là sai và bạn cần nhận phản hồi để tìm hiểu làm thế nào.
Như một gợi ý cuối cùng, đừng nói chung cụm từ câu chuyện theo quan điểm của người dùng (kịch bản, có, nhưng không phải câu chuyện). Chúng không phải là những câu chuyện của người dùng. Có lẽ nên đọc một cái gì đó như:
In order to attract people to my website
As @thom
I want users to easily convert months and days to days.
Dù sao, có một số mục tiêu cấp cao hơn mà bạn đang tìm kiếm. Điều này cũng sẽ giúp bạn rút ra những khả năng bạn cần. Chúc may mắn với nó, và xin lỗi cho bài viết quá dài.