Làm thế nào để phát triển hướng hành vi cải thiện sự rõ ràng khi ngôn ngữ tự nhiên không rõ ràng?

Tôi hiện đang khám phá các khung kiểm tra BDD như dưa chuột và tôi thấy tò mò khi mọi người nói

vì các tệp tính năng là ngôn ngữ tự nhiên đơn giản, nó cải thiện sự rõ ràng và mang lại một tầm nhìn rõ ràng

nhưng, ngôn ngữ tự nhiên không phải là nguyên nhân của hầu hết các rắc rối chúng ta gặp phải trong Kỹ thuật phần mềm?

Ngôn ngữ tự nhiên không rõ ràng và đó là lý do khiến nhiều dự án phần mềm thất bại vì giải thích sai các yêu cầu của khách hàng và sự hiểu biết của nhà phát triển. Tôi không có được chỗ đứng ở đây.

Vâng, chia nhỏ các bài kiểm tra thành các hành động đơn giản nhỏ bé có ý nghĩa và mang lại một mức độ rõ ràng nhất định nhưng điều đó có cải thiện năng suất nói chung không?

Tái bút: Tôi không phải là chuyên gia và tôi không đưa ra ý kiến ​​ở đây. Tôi chỉ tò mò muốn hiểu khái niệm.

Bạn nói đúng. BDD không loại bỏ các vấn đề với sự mơ hồ ngôn ngữ - hoàn toàn không. Như những người khác đã chỉ ra, các đoạn được dịch cần phải được khớp bằng cách xác định đúng chúng, nhưng điều này cũng không giải quyết được vấn đề mơ hồ tiềm ẩn.

Bây giờ tại sao BDD thực sự có giá trị mặc dù không giải quyết vấn đề này? Có một số lý do và danh sách này chắc chắn không đầy đủ.

Sự mơ hồ chưa được giải quyết

Đây không phải là một lý do có lợi cho BDD cũng như chống lại nó. Nhưng khi bạn đối chiếu nó với các cách tiếp cận khác như câu chuyện hoặc yêu cầu của người dùng, thì tất cả các cách tiếp cận phát triển SW đều gặp phải sự mơ hồ về ngôn ngữ vì tất cả đều bắt đầu theo cách này hay cách khác với công thức ngôn ngữ tự nhiên.

Về mặt kỹ thuật, vấn đề mơ hồ ngôn ngữ đã được giải quyết bằng các ngôn ngữ nhân tạo như lojban , nhưng một lần nữa, khách hàng và nhà phát triển của bạn rất có thể sẽ không biết ngôn ngữ đó.

Ngôn ngữ phổ biến

BDD đi đôi với ý tưởng về một ngôn ngữ có mặt khắp nơi. Có thể chỉ định các kịch bản cùng với tất cả khách hàng, người thử nghiệm và nhà phát triển, chỉ mang lại cho BDD một lợi thế so với các phương pháp khác.

Xem xét một kỹ sư yêu cầu truyền thống viết ra tất cả các yêu cầu. Khi bạn là người kiểm tra hoặc khách hàng nhận được tài liệu 300 trang có đầy đủ các yêu cầu để xem xét, bạn sẽ gặp nhiều vấn đề cấp bách hơn thuật ngữ được sử dụng ở đó.

Câu chuyện của người dùng làm tốt hơn một chút trên mặt trận đó, vì họ cũng bao gồm tất cả các bên liên quan trong sáng tạo của họ. Về mặt ngôn ngữ phổ biến, tôi sẽ không nói rằng các câu chuyện của người dùng hoặc BDD là tốt hơn - mặc dù chúng khác nhau đáng kể ở điểm tiếp theo.

Khả năng kiểm tra

Một khía cạnh chính của BDD là thông số kỹ thuật của bạn thực sự có thể thực hiện được (thông qua Cucumber hoặc tương tự). Không có yêu cầu cũng như câu chuyện người dùng cung cấp tính năng này. Đối với cá nhân tôi, đó là điểm bán hàng chính của BDD.

Trái ngược với yêu cầu truyền thống - chúng tôi đã nói với các kỹ sư yêu cầu từ lâu rằng các yêu cầu của họ phải có thể kiểm tra được. Tuy nhiên, mọi dự án đều thấy một trường hợp ở đâu đó, những người kiểm tra trực tuyến nhận ra rằng họ không biết làm thế nào để kiểm tra một yêu cầu nhất định.

Câu chuyện của người dùng, nếu được thực hiện đúng, bao gồm những người thử nghiệm trong giai đoạn sáng tạo ban đầu của họ để đảm bảo điều đó. Thật không may, đây là một trường hợp lý thuyết đụng độ với thế giới thực, nơi tôi đã thấy rất nhiều câu chuyện mà chưa có người thử nghiệm nào nhìn thấy trước đây.

Mặt khác, BDD tự động cung cấp cho bạn một kịch bản thử nghiệm có thể thực hiện được. Không có lời bào chữa và không có cách nào khác (trừ khi bạn hoàn toàn bỏ qua các lớp tự động hóa và chỉ viết ra các kịch bản cho thơ ưa thích).

Tổng quát hơn, Test First là một nguyên tắc rất bổ ích trong tất cả các giai đoạn phát triển phần mềm và BDD là ứng dụng của nó cho lớp ngoài cùng của sự phát triển (so với TDD ở cấp độ đơn vị).

Tóm lược

Tóm lại, BDD không nâng bạn khỏi những vấn đề mơ hồ về ngôn ngữ tự nhiên. Tuy nhiên, nó giúp bạn giải quyết vấn đề đó thông qua hai điểm quan trọng: Tập trung vào một ngôn ngữ phổ biến để giảm sự mơ hồ (nó sẽ loại bỏ hoàn toàn chúng, nhưng nó giúp ích rất nhiều!) Và bằng cách buộc bạn phải viết thực thi thông số kỹ thuật. Điểm thứ hai là giúp giải quyết các vấn đề mơ hồ chủ yếu là vì đó là điểm mà sự mơ hồ bắt đầu hiển thị như các vấn đề khác.

Khi một cái gì đó được viết bằng ngôn ngữ tự nhiên, thì điều này có thể có nghĩa là một số điều:

• Đây là nghĩa đen của tiếng Anh. Vì tiếng Anh là một ngôn ngữ rất mơ hồ và thiếu chính xác, chế độ đầu vào này không thỏa mãn trong bối cảnh phát triển phần mềm.

• Đây là tiếng Anh, nhưng các thuật ngữ có liên quan được xác định chính xác. Ngôn ngữ như vậy được sử dụng trong các tài liệu pháp lý, hoặc các văn bản toán học.

• Đây là một ngôn ngữ chính thức, nhưng ngôn ngữ được mô hình hóa rất chặt chẽ sau các quy ước của ngôn ngữ tự nhiên. Điều này mô tả tất cả các ngôn ngữ lập trình, ở một mức độ nào đó. Ngôn ngữ chính thức càng giống tiếng Anh thì càng dễ hiểu đối với những người đọc chưa được đào tạo. Các ví dụ đáng chú ý về ngôn ngữ lập trình với mục tiêu này bao gồm COBOL và SQL: select id, name from persons where age > 18ngay lập tức rõ ràng. Nhược điểm của các ngôn ngữ này là bạn cần phải hiểu ngôn ngữ chính thức để viết mã làm việc. Ngoài ra, những ngôn ngữ này thường rất dài dòng.

DDD gợi ý rằng dự án sử dụng một ngôn ngữ phổ biến để mô tả tên miền. Đây thực chất là trường hợp 2: xác định các thuật ngữ có liên quan để bạn có thể giao tiếp chính xác trong ngôn ngữ tự nhiên.

Bản thân dưa chuột là trường hợp 3: một ngôn ngữ chính thức có ý định đọc rất gần với tiếng Anh thông thường. Chính xác hơn: Cucumber là một khung cho phép bạn xác định một ngôn ngữ chính thức đơn giản có thể được sử dụng để diễn đạt các yêu cầu / bài kiểm tra. Vấn đề ở đây là cùng một tài liệu đại diện cho các yêu cầu ngôn ngữ tự nhiên và các bài kiểm tra thực thi tự động, vì vậy cả hai sẽ luôn đồng bộ. Bạn có thể đọc một kịch bản dưa chuột và xác minh rằng nó thể hiện chính xác yêu cầu của bạn mà không cần phải hiểu tất cả những điều này hoạt động như thế nào.

Dưa chuột hoạt động bằng cách kết hợp tài liệu với các đoạn đã biết của ngôn ngữ tự nhiên. Những đoạn này phải được xác định đầu tiên. Để viết một kịch bản trong Cucumber, bạn cần lưu ý về các đoạn có sẵn - phần mềm sẽ không đọc được suy nghĩ của bạn. Các đoạn mã này cũng là nguồn gốc của các vấn đề có thể xảy ra: Khi bạn triển khai hành vi của đoạn văn bản, mã của bạn có thể làm điều gì đó hơi khác so với văn bản đoạn trích gợi ý. Đây không phải là một vấn đề nếu cùng một đoạn được sử dụng nhiều lần. Do đó, dưa chuột rất phù hợp để mô tả các quy tắc kinh doanh bao gồm một tập hợp nhỏ hơn các điều kiện, hành động và kết quả. Các khung kiểm tra khác có thể tốt hơn nếu mỗi đoạn mã chỉ được sử dụng một hoặc hai lần, ví dụ: vì thiết lập cho mỗi trường hợp thử nghiệm là duy nhất.

@ Raghuram8892, văn bản sau các từ khóa Cho / Khi / Sau đó / Và phải khớp với "đoạn trích", nếu không, bước không thành công là không xác định hoặc "đang chờ xử lý". Như vậy, nó rơi thẳng vào trường hợp 3.

Về "tiếng Anh", dưa chuột và ngôn ngữ của nó, Gherkin được thiết kế để sử dụng quốc tế. Bạn có thể gọi lệnh, cucumber --i18n helpđể xem danh sách các ngôn ngữ hiện được hỗ trợ và cucumber --i18n $CODEđể xem các từ khóa cho một mã ngôn ngữ cụ thể. Ví dụ: cucumber --i18n eođưa ra các từ khóa cho Esperanto.