Phát triển theo hướng hành vi - Hướng dẫn nhanh

Phát triển theo hướng hành vi (BDD) là một quá trình phát triển phần mềm ban đầu xuất hiện từ Phát triển theo hướng kiểm tra (TDD).

Theo Dan North, người chịu trách nhiệm về sự phát triển của BDD, “BDD đang sử dụng các ví dụ ở nhiều cấp độ để tạo ra sự hiểu biết chung và sự không chắc chắn bề mặt để cung cấp phần mềm quan trọng.”

BDD sử dụng các ví dụ để minh họa hoạt động của hệ thống được viết bằng ngôn ngữ dễ đọc và dễ hiểu cho mọi người tham gia vào quá trình phát triển. Những ví dụ này bao gồm -

Được chuyển đổi thành các thông số kỹ thuật thực thi.
Được sử dụng như các bài kiểm tra chấp nhận.

BDD - Các tính năng chính

Phát triển theo hướng hành vi tập trung vào -

Cung cấp quy trình dùng chung và các công cụ dùng chung thúc đẩy giao tiếp với các nhà phát triển phần mềm, nhà phân tích kinh doanh và các bên liên quan để hợp tác phát triển phần mềm, nhằm mục đích cung cấp sản phẩm có giá trị kinh doanh.
Hệ thống nên làm gì và không nên thực hiện như thế nào.
Cung cấp khả năng đọc và khả năng hiển thị tốt hơn.
Xác minh không chỉ hoạt động của phần mềm mà nó còn đáp ứng mong đợi của khách hàng.

Nguồn gốc của BDD

Chi phí để sửa chữa một lỗi sẽ tăng lên gấp nhiều lần nếu lỗi không được phát hiện đúng lúc và được sửa ngay khi nó được phát hiện. Hãy xem xét ví dụ sau.

Điều này cho thấy rằng trừ khi các yêu cầu được đạt được một cách chính xác, sẽ rất tốn kém để sửa chữa các khuyết tật do hiểu sai các yêu cầu ở giai đoạn sau. Hơn nữa, sản phẩm cuối cùng có thể không đáp ứng được mong đợi của khách hàng.

Sự cần thiết của giờ là một cách tiếp cận phát triển -

Là dựa trên các yêu cầu.
Tập trung vào các yêu cầu trong suốt quá trình phát triển.
Đảm bảo rằng các yêu cầu được đáp ứng.

Một cách tiếp cận phát triển có thể đáp ứng các yêu cầu nêu trên là BDD. Do đó, phát triển theo hướng hành vi -

Xuất phát các ví dụ về các hành vi mong đợi khác nhau của hệ thống.
Cho phép viết các ví dụ bằng ngôn ngữ sử dụng các thuật ngữ miền doanh nghiệp để đảm bảo mọi người tham gia vào quá trình phát triển bao gồm cả khách hàng dễ hiểu.
Thỉnh thoảng nhận được các ví dụ được khách hàng phê chuẩn bằng các cuộc trò chuyện.
Tập trung vào các yêu cầu của khách hàng (ví dụ) trong suốt quá trình phát triển.
Sử dụng các ví dụ làm kiểm tra chấp nhận.

Thực hành BDD

Hai thực hành chính của BDD là -

Đặc điểm kỹ thuật theo ví dụ (SbE)
Phát triển theo hướng kiểm tra (TDD)

Đặc điểm kỹ thuật theo ví dụ

Đặc tả theo Ví dụ (SbE) sử dụng các ví dụ trong các cuộc hội thoại để minh họa các quy tắc nghiệp vụ và hành vi của phần mềm sẽ được xây dựng.

Đặc tả bằng ví dụ cho phép chủ sở hữu sản phẩm, nhà phân tích kinh doanh, người kiểm tra và nhà phát triển loại bỏ những hiểu lầm phổ biến về các yêu cầu kinh doanh.

Hướng phát triển thử nghiệm

Phát triển theo hướng kiểm tra, trong bối cảnh của BDD, biến các ví dụ thành các thông số kỹ thuật có thể đọc và thực thi được.

Các nhà phát triển sử dụng các thông số kỹ thuật này như một hướng dẫn để triển khai các phần tăng thêm của chức năng mới. Điều này, dẫn đến một cơ sở mã gọn nhẹ và một bộ kiểm tra hồi quy tự động giúp giữ cho chi phí bảo trì thấp trong suốt vòng đời của phần mềm.

BDD nhanh nhẹn

Trong phát triển phần mềm Agile, phương pháp BDD được sử dụng để hiểu chung về các thông số kỹ thuật đang chờ xử lý.

Các bước sau được thực thi trong Agile BDD:

Các nhà phát triển và chủ sở hữu sản phẩm cộng tác viết các thông số kỹ thuật đang chờ xử lý trong một trình soạn thảo văn bản thuần túy.
Chủ sở hữu sản phẩm chỉ định các hành vi mà họ mong đợi từ hệ thống.
Các nhà phát triển
- Điền vào các thông số kỹ thuật với các chi tiết hành vi này.
- Đặt câu hỏi dựa trên sự hiểu biết của họ về hệ thống.
Các hành vi hệ thống hiện tại được xem xét để xem liệu tính năng mới có phá vỡ bất kỳ tính năng hiện có nào hay không.

Tuyên ngôn Agile và BDD

Tuyên ngôn Agile nêu rõ những điều sau:

Chúng tôi đang khám phá ra những cách tốt hơn để phát triển phần mềm bằng cách thực hiện nó và giúp những người khác làm điều đó. Thông qua công việc này, chúng tôi đã hiểu ra giá trị -

Individuals and interactions - qua các quy trình và công cụ
Working software - trên toàn bộ tài liệu
Customer collaboration - đàm phán hợp đồng
Responding to change - qua một kế hoạch

Có nghĩa là, trong khi có giá trị trong các mục ở bên phải, chúng ta đánh giá các mục ở bên trái nhiều hơn.

BDD tự phù hợp với tuyên ngôn Agile như sau:

Tuyên ngôn Agile	Căn chỉnh BDD
Các cá nhân và tương tác qua các quy trình và công cụ.	BDD là về các cuộc trò chuyện.
Phần mềm làm việc trên tài liệu toàn diện.	BDD tập trung vào việc giúp dễ dàng tạo ra phần mềm có giá trị kinh doanh.
Hợp tác với khách hàng trong quá trình đàm phán hợp đồng.	BDD tập trung vào các kịch bản dựa trên ý tưởng với sự liên lạc liên tục với khách hàng trong quá trình phát triển. Nó không dựa trên bất kỳ lời hứa nào.
Đáp ứng sự thay đổi so với việc tuân theo một kế hoạch.	BDD tập trung vào giao tiếp và cộng tác liên tục để tạo điều kiện thuận lợi cho việc hấp thụ các thay đổi.

Khi bạn xem bất kỳ tài liệu tham khảo nào về Phát triển theo hướng hành vi, bạn sẽ thấy cách sử dụng các cụm từ như “BDD có nguồn gốc từ TDD”, “BDD và TDD”. Để biết BDD ra đời như thế nào, tại sao nó được cho là bắt nguồn từ TDD và BDD và TDD là gì, bạn phải hiểu về TDD.

Tại sao phải thử nghiệm?

Để bắt đầu, chúng ta hãy đi vào các nguyên tắc cơ bản của thử nghiệm. Mục đích của thử nghiệm là để đảm bảo rằng hệ thống được xây dựng đang hoạt động như mong đợi. Hãy xem xét ví dụ sau.

Do đó, bằng kinh nghiệm, chúng tôi đã học được rằng việc phát hiện ra một khiếm khuyết khi nó được đưa ra và sửa chữa nó ngay lập tức sẽ có hiệu quả về chi phí. Do đó, có sự cần thiết của việc viết các trường hợp kiểm thử ở mọi giai đoạn phát triển và kiểm thử. Đây là những gì các phương pháp kiểm tra truyền thống của chúng tôi đã dạy chúng tôi, thường được gọi là Thử nghiệm sớm.

Phương pháp thử nghiệm này được gọi là phương pháp Thử nghiệm-Cuối cùng vì thử nghiệm được thực hiện sau khi hoàn thành một giai đoạn.

Những thách thức với Phương pháp tiếp cận thử nghiệm-lần cuối

Cách tiếp cận Kiểm tra-Cuối cùng đã được theo sau trong một thời gian dài trong các dự án phát triển phần mềm. Tuy nhiên, trên thực tế, với cách tiếp cận này, vì quá trình thử nghiệm phải đợi cho đến khi giai đoạn cụ thể hoàn thành, nên nó thường bị bỏ qua vì -

Sự chậm trễ trong việc hoàn thành giai đoạn.
Thời gian biểu chặt chẽ.
Tập trung vào việc giao hàng đúng giờ, bỏ qua khâu kiểm tra.

Hơn nữa, trong cách tiếp cận Kiểm tra-Cuối cùng, Kiểm thử đơn vị, được cho là do các nhà phát triển thực hiện thường bị bỏ qua. Các lý do khác nhau được tìm thấy dựa trên tư duy của các nhà phát triển -

Họ là nhà phát triển chứ không phải người thử nghiệm.
Kiểm tra là trách nhiệm của những người kiểm tra.
Họ mã hóa hiệu quả và mã của họ sẽ không có lỗi.

Điều này dẫn đến -

Thỏa hiệp về chất lượng của sản phẩm được giao.
Chỉ có trách nhiệm giải trình về chất lượng cho người kiểm tra.
Chi phí cao trong việc sửa chữa các lỗi, chuyển phát sau.
Không có khả năng đạt được sự hài lòng của khách hàng, điều này cũng có nghĩa là mất công việc kinh doanh lặp lại, do đó ảnh hưởng đến uy tín.

Những yếu tố này đã kêu gọi sự thay đổi mô hình, để tập trung vào thử nghiệm. Kết quả là phương pháp Thử nghiệm Đầu tiên.

Phương pháp tiếp cận thử nghiệm đầu tiên

Cách tiếp cận Test-First thay thế cách phát triển từ trong ra ngoài (viết mã và sau đó kiểm tra) thành cách phát triển từ bên ngoài vào (viết bài kiểm tra và sau đó viết mã).

Cách tiếp cận này được kết hợp với các phương pháp luận phát triển phần mềm sau đây (cũng là Agile) -

eXtreme Programming (XP).
Test Driven Dsự phát triển (TDD).

Trong các phương pháp luận này, nhà phát triển thiết kế và viết các bài kiểm tra Đơn vị cho một mô-đun mã trước khi viết một dòng duy nhất của mô-đun mã. Sau đó, nhà phát triển tạo mô-đun mã với mục tiêu vượt qua bài kiểm tra Đơn vị. Do đó, các phương pháp này sử dụng Kiểm thử đơn vị để thúc đẩy sự phát triển.

Điểm cơ bản cần lưu ý rằng mục tiêu là phát triển dựa trên thử nghiệm.

Chu kỳ Red-Green-Refactor

Test Driven Development được sử dụng để phát triển mã được hướng dẫn bởi Unit tests.

Step 1 - Hãy xem xét một mô-đun mã sẽ được viết.

Step 2 - Viết bài kiểm tra

Step 3 - Chạy thử nghiệm.

Kiểm tra không thành công, vì mã vẫn chưa được viết. Do đó, Bước 2 thường được gọi là viết một bài kiểm tra không đạt.

Step 4 - Viết mã tối thiểu có thể để vượt qua bài kiểm tra.

Step 5- Chạy tất cả các bài kiểm tra để đảm bảo rằng tất cả chúng vẫn vượt qua. Các bài kiểm tra đơn vị được tự động hóa để hỗ trợ bước này.

Step 6 - Cơ cấu lại.

Step 7 - Lặp lại Bước 1 đến Bước 6 cho mô-đun mã tiếp theo.

Mỗi chu kỳ phải rất ngắn, và một giờ điển hình nên chứa nhiều chu kỳ.

Điều này còn được gọi phổ biến là Red-Green-Refactor chu kỳ, nơi -

Red - Viết bài kiểm tra không đạt.
Green - Viết mã để vượt qua bài kiểm tra.
Refactor - Loại bỏ sự trùng lặp và cải tiến mã theo các tiêu chuẩn được chấp nhận.

Các bước xử lý TDD

Các bước của quy trình TDD được minh họa dưới đây.

Ưu điểm của TDD

Các lợi ích hoặc lợi thế của Phát triển theo hướng thử nghiệm là:

Trước tiên, nhà phát triển cần phải hiểu kết quả mong muốn là gì và cách kiểm tra nó trước khi tạo mã.
Mã cho một thành phần chỉ hoàn thành khi quá trình kiểm tra vượt qua và mã được cấu trúc lại. Điều này đảm bảo thử nghiệm và tái cấu trúc trước khi nhà phát triển chuyển sang thử nghiệm tiếp theo.
Khi bộ bài kiểm tra Đơn vị được chạy sau mỗi lần tái cấu trúc, phản hồi rằng mỗi thành phần vẫn hoạt động là không đổi.
Các bài kiểm tra Đơn vị hoạt động như một tài liệu sống luôn cập nhật dữ liệu.
Nếu một lỗi được tìm thấy, nhà phát triển sẽ tạo một bài kiểm tra để tiết lộ lỗi đó và sau đó sửa đổi mã để bài kiểm tra vượt qua và lỗi được sửa. Điều này làm giảm thời gian gỡ lỗi. Tất cả các bài kiểm tra khác cũng được chạy và khi chúng vượt qua, nó đảm bảo rằng chức năng hiện có không bị hỏng
Nhà phát triển có thể đưa ra quyết định thiết kế và cấu trúc lại bất kỳ lúc nào và việc chạy các bài kiểm tra đảm bảo rằng hệ thống vẫn hoạt động. Điều này làm cho phần mềm có thể bảo trì được.
Nhà phát triển tự tin sẽ thực hiện bất kỳ thay đổi nào vì nếu thay đổi ảnh hưởng đến bất kỳ chức năng hiện có nào, điều tương tự sẽ được tiết lộ bằng cách chạy thử nghiệm và các lỗi có thể được sửa ngay lập tức.
Trên mỗi lần chạy thử nghiệm liên tiếp, tất cả các sửa chữa lỗi trước đó cũng được xác minh và việc lặp lại lỗi tương tự được giảm bớt.
Vì hầu hết các thử nghiệm được thực hiện trong quá trình phát triển, nên việc thử nghiệm trước khi giao hàng được rút ngắn.

Nhược điểm của TDD

Điểm khởi đầu là Câu chuyện người dùng, mô tả hành vi của hệ thống. Do đó, các nhà phát triển thường gặp phải những câu hỏi sau:

Kiểm tra khi nào?
Kiểm tra những gì?
Làm thế nào để biết nếu một thông số kỹ thuật được đáp ứng?
Mã có mang lại giá trị kinh doanh không?

Những quan niệm sai lầm về TDD

Những quan niệm sai lầm sau đây tồn tại trong ngành và cần được làm rõ.

Quan niệm sai lầm	Làm rõ
TDD là tất cả về thử nghiệm và tự động hóa thử nghiệm.	TDD là một phương pháp phát triển sử dụng cách tiếp cận Test-First.
TDD không liên quan đến bất kỳ thiết kế nào.	TDD bao gồm phân tích quan trọng và thiết kế dựa trên các yêu cầu. Thiết kế xuất hiện trong quá trình phát triển.
TDD chỉ ở mức Đơn vị.	TDD có thể được sử dụng ở cấp độ tích hợp và hệ thống.
TDD không thể được sử dụng bởi các dự án thử nghiệm truyền thống.	TDD trở nên phổ biến với Lập trình cực đoan và đang được sử dụng trong các phương pháp Agile khác. Tuy nhiên, nó cũng có thể được sử dụng trong các dự án thử nghiệm truyền thống.
TDD là một công cụ.	TDD là một phương pháp phát triển và sau khi mỗi Bài kiểm tra đơn vị mới vượt qua, nó sẽ được thêm vào Bộ kiểm tra tự động hóa vì tất cả các bài kiểm tra cần được chạy bất cứ khi nào mã mới được thêm vào hoặc mã hiện có được sửa đổi và cũng như sau mỗi lần tái cấu trúc. Do đó, các Công cụ Tự động hóa Kiểm tra hỗ trợ TDD tạo điều kiện thuận lợi cho quá trình này.
TDD có nghĩa là giao các bài kiểm tra Chấp nhận cho các nhà phát triển.	TDD không có nghĩa là giao Kiểm tra chấp nhận cho nhà phát triển.

Chấp nhận TDD

Phát triển theo hướng kiểm tra chấp nhận (ATDD) xác định Tiêu chí chấp nhận và Kiểm tra chấp nhận trong quá trình tạo Câu chuyện người dùng, trong giai đoạn đầu phát triển. ATDD tập trung vào giao tiếp và hiểu biết chung giữa khách hàng, nhà phát triển và người thử nghiệm.

Các thực hành chính trong ATDD như sau:

Thảo luận về các tình huống trong thế giới thực để xây dựng sự hiểu biết chung về miền.
Sử dụng các tình huống đó để đạt được tiêu chí chấp nhận.
Tự động hóa các bài kiểm tra Chấp nhận.
Tập trung sự phát triển vào các bài kiểm tra đó.
Sử dụng các bài kiểm tra như một thông số kỹ thuật trực tiếp để tạo điều kiện thay đổi.

Các lợi ích của việc sử dụng ATDD như sau:

Yêu cầu rõ ràng và không có khoảng cách chức năng.
Những người khác hiểu những trường hợp đặc biệt mà các nhà phát triển thấy trước.
Các bài kiểm tra Chấp nhận hướng dẫn sự phát triển.

TDD Vs BDD

Theo Dan North, các lập trình viên thường gặp phải các vấn đề sau khi thực hiện Phát triển theo hướng kiểm tra -

Bắt đầu từ đâu
Những gì để kiểm tra và những gì không nên kiểm tra
Kiểm tra bao nhiêu trong một lần
Bài kiểm tra của họ được gọi là gì
Làm thế nào để hiểu tại sao một bài kiểm tra không thành công

Giải pháp cho tất cả những vấn đề này là Phát triển theo hướng hành vi. Nó đã phát triển từ các thực hành nhanh đã được thiết lập và được thiết kế để làm cho chúng dễ tiếp cận hơn và hiệu quả hơn cho các nhóm, mới đối với phân phối phần mềm nhanh. Theo thời gian, BDD đã phát triển để bao quát bức tranh rộng hơn về phân tích nhanh và kiểm thử chấp nhận tự động.

Chính difference between TDD and BDD đó là -

TDD mô tả cách hoạt động của phần mềm.
Mặt khác, BDD -
- Mô tả cách người dùng cuối sử dụng phần mềm.
- Thúc đẩy sự hợp tác và giao tiếp.
- Nhấn mạnh vào các ví dụ về hành vi của Hệ thống.
- Nhắm vào các đặc tả thực thi được lấy từ các ví dụ

Trong TDD, thuật ngữ “Kiểm tra chấp nhận” bị hiểu nhầm. Kiểm thử chấp nhận thực sự đại diện cho hành vi mong đợi của hệ thống. Trong thực hành Agile, sự hợp tác của cả nhóm và tương tác với khách hàng và các bên liên quan khác được nhấn mạnh. Điều này đã làm phát sinh sự cần thiết của việc sử dụng các thuật ngữ mà mọi người tham gia dự án dễ hiểu.

TDD khiến bạn suy nghĩ về những điều bắt buộc Behavior và do đó thuật ngữ 'Hành vi' hữu ích hơn thuật ngữ ‘Test’. BDD là Phát triển theo hướng kiểm tra với từ vựng tập trung vào hành vi chứ không phải kiểm tra.

Theo lời của Dan North, “Tôi nhận thấy sự thay đổi từ suy nghĩ trong các bài kiểm tra sang suy nghĩ trong hành vi sâu sắc đến mức tôi bắt đầu gọi TDD là BDD, hoặc Phát triển theo hướng hành vi.” TDD tập trung vào cách một thứ gì đó sẽ hoạt động, BDD tập trung vào lý do tại sao chúng tôi xây dựng nó.

BDD trả lời các câu hỏi sau mà các nhà phát triển thường gặp phải -

Câu hỏi	Câu trả lời
Bắt đầu từ đâu?	ngoài vào trong
Kiểm tra những gì?	Câu chuyện của người dùng
Những gì không để kiểm tra?	còn gì nữa không

Những câu trả lời này dẫn đến khung câu chuyện như sau:

Story Framework

Như một [Role]

tôi muốn [Feature]

vậy nên [Benefit]

Điều này có nghĩa là, 'Khi một Feature được thực thi, kết quả Benefit là cho Người chơi Role.'

BDD trả lời thêm các câu hỏi sau:

Câu hỏi	Câu trả lời
Bao nhiêu để kiểm tra trong một lần?	rất ít tập trung
Những gì để gọi các bài kiểm tra của họ?	mẫu câu
Làm thế nào để hiểu tại sao một bài kiểm tra không thành công	tài liệu

Những câu trả lời này dẫn đến khung Ví dụ như sau:

Example Framework

Given một số bối cảnh ban đầu,

When một sự kiện xảy ra,

Then đảm bảo một số kết quả.

Điều này có nghĩa là, 'Bắt đầu với bối cảnh ban đầu, khi một sự kiện cụ thể xảy ra, chúng ta biết kết quả should be. '

Vì vậy, ví dụ cho thấy hành vi mong đợi của hệ thống. Các ví dụ được sử dụng để minh họa các tình huống khác nhau của hệ thống.

Câu chuyện và kịch bản

Chúng ta hãy xem xét minh họa sau đây của Dan North về hệ thống ATM.

Câu chuyện

As a khách hàng,

I want rút tiền mặt từ máy ATM,

so that Tôi không phải xếp hàng chờ đợi tại ngân hàng.

Các tình huống

Có hai tình huống có thể xảy ra cho câu chuyện này.

Scenario 1 - Tài khoản được ghi có

Given tài khoản có tín dụng

And thẻ hợp lệ

And máy rút chứa tiền mặt

When khách hàng yêu cầu tiền mặt

Then đảm bảo tài khoản được ghi nợ

And đảm bảo tiền mặt được phân phối

And đảm bảo thẻ được trả lại

Scenario 2 - Tài khoản được thấu chi vượt quá hạn mức thấu chi

Given tài khoản được thấu chi

And thẻ hợp lệ

When khách hàng yêu cầu tiền mặt

Then đảm bảo thông báo từ chối được hiển thị

And đảm bảo tiền mặt không được phân phối

And đảm bảo thẻ được trả lại

Sự kiện giống nhau trong cả hai tình huống, nhưng bối cảnh khác nhau. Do đó, các kết quả khác nhau.

Chu kỳ phát triển

Chu kỳ phát triển cho BDD là một outside-in tiếp cận.

Step 1- Viết ví dụ về giá trị doanh nghiệp cấp cao (bên ngoài) (sử dụng Cucumber hoặc RSpec / Capybara) có màu đỏ. (RSpec tạo khung công tác BDD bằng ngôn ngữ Ruby)

Step 2 - Viết ví dụ RSpec cấp thấp hơn (bên trong) cho bước triển khai đầu tiên có màu đỏ.

Step 3 - Triển khai mã tối thiểu để vượt qua ví dụ cấp thấp hơn đó, thấy nó chuyển sang màu xanh lục.

Step 4 - Viết ví dụ RSpec cấp thấp hơn tiếp theo để chuyển sang Bước 1 có màu đỏ.

Step 5 - Lặp lại các bước Bước 3 và Bước 4 cho đến khi ví dụ cấp cao trong Bước 1 chuyển sang màu xanh lục.

Note - Cần ghi nhớ những điểm sau:

Red/green trạng thái là một trạng thái quyền.
Khi các bài kiểm tra cấp thấp của bạn có màu xanh lục, bạn có quyền viết các ví dụ mới hoặc cấu trúc lại việc triển khai hiện có. Bạn không được, trong bối cảnh tái cấu trúc, thêm chức năng / tính linh hoạt mới.
Khi các thử nghiệm cấp thấp của bạn có màu đỏ, bạn chỉ có quyền viết hoặc thay đổi mã triển khai để làm cho các thử nghiệm hiện có chuyển sang màu xanh lục. Bạn phải chống lại sự thôi thúc viết mã để vượt qua bài kiểm tra tiếp theo không tồn tại hoặc triển khai các tính năng mà bạn có thể cho là tốt (khách hàng sẽ không yêu cầu).

Theo Gojko Adzic, tác giả của 'Đặc tả theo ví dụ', Đặc tả theo ví dụ là một tập hợp các mẫu quy trình tạo điều kiện thuận lợi cho việc thay đổi các sản phẩm phần mềm để đảm bảo rằng sản phẩm phù hợp được phân phối một cách hiệu quả. "

Đặc tả bằng ví dụ là một cách tiếp cận hợp tác để xác định các yêu cầu và kiểm tra chức năng theo định hướng kinh doanh cho các sản phẩm phần mềm dựa trên việc nắm bắt và minh họa các yêu cầu bằng cách sử dụng các ví dụ thực tế thay vì các câu lệnh trừu tượng.

Đặc tả theo ví dụ - Tổng quan

Mục tiêu của Đặc tả theo Ví dụ là tập trung vào việc phát triển và cung cấp các yêu cầu kinh doanh được ưu tiên, có thể xác minh được. Mặc dù bản thân khái niệm Đặc tả bằng ví dụ là tương đối mới, nhưng nó chỉ đơn giản là sự diễn đạt lại các thực hành hiện có.

Nó hỗ trợ một từ vựng rất cụ thể, ngắn gọn được gọi là ngôn ngữ phổ biến -

Cho phép các yêu cầu thực thi.
Được mọi người trong đội sử dụng.
Được tạo ra bởi một nhóm chức năng chéo.
Nắm bắt sự hiểu biết của mọi người.

Đặc tả bằng Ví dụ có thể được sử dụng như một đầu vào trực tiếp để xây dựng các Thử nghiệm tự động phản ánh lĩnh vực kinh doanh. Vì vậy, trọng tâm của Đặc tả kỹ thuật bằng ví dụ là xây dựng sản phẩm phù hợp và xây dựng sản phẩm phù hợp.

Mục đích của Đặc điểm kỹ thuật theo Ví dụ

Mục đích chính của Đặc tả theo Ví dụ là xây dựng sản phẩm phù hợp. Nó tập trung vào sự hiểu biết được chia sẻ, do đó thiết lập một nguồn chân lý duy nhất. Nó cho phép tự động hóa các tiêu chí chấp nhận để tập trung vào việc ngăn ngừa lỗi hơn là phát hiện lỗi. Nó cũng thúc đẩy việc kiểm tra sớm để tìm ra các khiếm khuyết sớm.

Sử dụng SbE

Đặc tả bằng Ví dụ được sử dụng để minh họa hành vi hệ thống mong đợi mô tả giá trị kinh doanh. Hình ảnh minh họa bằng các ví dụ cụ thể và thực tế. Những ví dụ này được sử dụng để tạo ra các yêu cầu thực thi:

Có thể kiểm tra mà không cần dịch.
Được chụp trong tài liệu trực tiếp.

Sau đây là những lý do tại sao chúng tôi sử dụng các ví dụ để mô tả các thông số kỹ thuật cụ thể -

Chúng dễ hiểu hơn.
Họ khó hiểu sai hơn.

Ưu điểm của SbE

Những lợi thế của việc sử dụng Đặc tả theo Ví dụ là:

Tăng chất lượng
Giảm lãng phí
Giảm nguy cơ lỗi sản xuất
Nỗ lực tập trung
Thay đổi có thể được thực hiện an toàn hơn
Cải thiện sự tham gia kinh doanh

Các ứng dụng của SbE

Đặc điểm kỹ thuật theo Ví dụ tìm ứng dụng trong -

Doanh nghiệp phức tạp hoặc tổ chức phức tạp.
Không hoạt động tốt đối với các vấn đề kỹ thuật thuần túy.
Không hoạt động tốt đối với các sản phẩm phần mềm tập trung vào giao diện người dùng.
Có thể được áp dụng cho các hệ thống kế thừa.

Kiểm tra SbE và Chấp nhận

Ưu điểm của Đặc tả kỹ thuật bằng Ví dụ trong điều kiện Kiểm tra chấp nhận là:

Một minh họa duy nhất được sử dụng cho cả hai, các yêu cầu chi tiết và thử nghiệm
Tiến độ của dự án đang được kiểm tra nghiệm thu -
- Mỗi bài kiểm tra là để kiểm tra một hành vi.
- Một bài kiểm tra là vượt qua cho một hành vi hoặc nó không.
- Một bài kiểm tra vượt qua cho thấy rằng hành vi cụ thể đã được hoàn thành.
- Nếu một dự án yêu cầu hoàn thành 100 hành vi mà 60 hành vi hoàn thành thì tức là đã hoàn thành 60%.
Người kiểm tra chuyển từ sửa lỗi sang ngăn ngừa lỗi và họ đóng góp vào việc thiết kế giải pháp.
Tự động hóa cho phép hiểu ngay tác động của sự thay đổi yêu cầu đối với giải pháp.

Đặc tả theo ví dụ - Ý nghĩa của nó đối với các Vai trò khác nhau

Mục tiêu của Đặc tả theo Ví dụ là thúc đẩy sự hợp tác của mọi người trong nhóm, bao gồm cả khách hàng trong suốt dự án để mang lại giá trị kinh doanh. Mọi người để dễ hiểu hơn hãy sử dụng cùng một Từ vựng.

Vai trò	Sử dụng SbE
Phân tích kinh doanh	Yêu cầu rõ ràng và không có khoảng cách chức năng. Các nhà phát triển, thực sự đọc các thông số kỹ thuật.
Nhà phát triển	Các nhà phát triển hiểu rõ hơn, những gì đang được phát triển. Tiến độ phát triển được theo dõi tốt hơn bằng cách đếm các thông số kỹ thuật đã được phát triển chính xác.
Kiểm thử	Người kiểm tra hiểu rõ hơn, những gì đang được kiểm tra. Người kiểm thử tham gia ngay từ đầu và có vai trò trong thiết kế. Người kiểm tra làm việc theo hướng ngăn ngừa lỗi hơn là phát hiện lỗi.
Tất cả mọi người	Thời gian được tiết kiệm bằng cách xác định lỗi ngay từ đầu. Một sản phẩm chất lượng được sản xuất ngay từ đầu.

SbE - Tập hợp các mẫu quy trình

Như chúng ta đã thấy ở phần đầu của chương này, Đặc tả theo Ví dụ được định nghĩa là một tập hợp các mẫu quy trình tạo điều kiện thuận lợi cho việc thay đổi các sản phẩm phần mềm để đảm bảo rằng sản phẩm phù hợp được phân phối một cách hiệu quả.

Các mẫu quy trình là -

Đặc tả cộng tác
Minh họa thông số kỹ thuật bằng các ví dụ
Tinh chỉnh đặc điểm kỹ thuật
Tự động hóa các ví dụ
Xác thực thường xuyên
Tài liệu sống

Đặc điểm cộng tác

Mục tiêu của đặc tả cộng tác là:

Nhận các vai trò khác nhau trong nhóm để có sự hiểu biết chung và từ vựng chung.
Thu hút mọi người tham gia vào dự án để họ có thể đóng góp những quan điểm khác nhau về một đối tượng địa lý.
Đảm bảo giao tiếp được chia sẻ và quyền sở hữu các tính năng.

Những mục tiêu này được đáp ứng trong một hội thảo đặc tả còn được gọi là cuộc họp Three Amigos. Ba Amigos là BA, QA và nhà phát triển. Mặc dù có những vai trò khác trong dự án, nhưng ba người này sẽ chịu trách nhiệm và chịu trách nhiệm từ định nghĩa cho đến việc cung cấp các tính năng.

During the meeting −

Nhà phân tích kinh doanh (BA) trình bày các yêu cầu và thử nghiệm cho một tính năng mới.
Ba Amigos (BA, Developer và QA) thảo luận về tính năng mới và xem xét các thông số kỹ thuật.
QA và nhà phát triển cũng xác định các yêu cầu còn thiếu.
Ba Amigos
- Sử dụng một mô hình được chia sẻ bằng một ngôn ngữ phổ biến.
- Sử dụng từ vựng miền (Bảng chú giải thuật ngữ được duy trì nếu cần).
- Tìm kiếm sự khác biệt và xung đột.
Đừng chuyển đến chi tiết triển khai tại thời điểm này.
Đạt được sự đồng thuận về việc một đối tượng địa lý đã được chỉ định đầy đủ hay chưa.
Ý thức chung về các yêu cầu và quyền sở hữu thử nghiệm tạo điều kiện thuận lợi cho các thông số chất lượng
Các yêu cầu được trình bày dưới dạng các tình huống, cung cấp các yêu cầu rõ ràng, rõ ràng. Một kịch bản là một ví dụ về hành vi của hệ thống từ quan điểm của người dùng.

Minh họa Đặc điểm kỹ thuật bằng các ví dụ

Các kịch bản được chỉ định bằng cách sử dụng cấu trúc Given-When-Then để tạo một đặc tả có thể kiểm tra -

Given <một số điều kiện tiên quyết>

And <điều kiện tiên quyết bổ sung> Optional

When <một hành động / kích hoạt xảy ra>

Then <một số điều kiện đăng>

And <điều kiện đăng bài bổ sung> Optional

Đặc tả này là một ví dụ về hành vi của hệ thống. Nó cũng đại diện cho một tiêu chí Chấp nhận của hệ thống.

Nhóm thảo luận về các ví dụ và phản hồi được tổng hợp cho đến khi có sự đồng ý rằng các ví dụ bao hàm hành vi mong đợi của đối tượng địa lý. Điều này đảm bảo phạm vi kiểm tra tốt.

Tinh chỉnh đặc điểm kỹ thuật

Để tinh chỉnh một thông số kỹ thuật,

Hãy viết chính xác các ví dụ. Nếu một ví dụ trở nên phức tạp, hãy chia nó thành các ví dụ đơn giản hơn.
Tập trung vào quan điểm kinh doanh và tránh các chi tiết kỹ thuật.
Xem xét cả điều kiện tích cực và tiêu cực.
Tuân thủ các từ vựng cụ thể của miền.
Thảo luận về các ví dụ với khách hàng.
- Chọn các cuộc trò chuyện để thực hiện điều này.
- Chỉ xem xét những ví dụ mà khách hàng quan tâm. Điều này chỉ cho phép sản xuất mã bắt buộc và tránh bao gồm mọi kết hợp có thể có, có thể không bắt buộc
Để đảm bảo rằng kịch bản vượt qua, tất cả các trường hợp kiểm thử cho kịch bản đó phải vượt qua. Do đó, hãy nâng cao các thông số kỹ thuật để chúng có thể kiểm tra được. Các trường hợp thử nghiệm có thể bao gồm các phạm vi và giá trị dữ liệu khác nhau (trường hợp ranh giới và góc) cũng như các quy tắc nghiệp vụ khác nhau dẫn đến thay đổi dữ liệu.
Chỉ định các quy tắc kinh doanh bổ sung như tính toán phức tạp, thao tác / chuyển đổi dữ liệu, v.v.
Bao gồm các tình huống phi chức năng (ví dụ: hiệu suất, tải, khả năng sử dụng, v.v.) dưới dạng Đặc tả theo Ví dụ

Tự động hóa ví dụ

Lớp tự động hóa cần được giữ rất đơn giản - chỉ nối dây của thông số kỹ thuật vào hệ thống đang thử nghiệm. Bạn có thể sử dụng một công cụ cho tương tự.

Thực hiện tự động hóa kiểm tra bằng cách sử dụng Ngôn ngữ dành riêng cho miền (DSL) và thể hiện kết nối rõ ràng giữa đầu vào và đầu ra. Tập trung vào đặc tả chứ không phải tập lệnh. Đảm bảo rằng các bài kiểm tra chính xác, dễ hiểu và có thể kiểm tra được.

Xác thực thường xuyên

Bao gồm xác thực ví dụ trong quy trình phát triển của bạn với mọi thay đổi (bổ sung / sửa đổi). Có nhiều kỹ thuật và công cụ có thể (và nên) được áp dụng để giúp đảm bảo chất lượng của sản phẩm. Chúng xoay quanh ba nguyên tắc chính-Test Early, Test Well và Test Often.

Thực hiện các bài kiểm tra thường xuyên để bạn có thể xác định các liên kết yếu. Các ví dụ đại diện cho các hành vi giúp theo dõi tiến trình và một hành vi được cho là chỉ hoàn thành sau khi bài kiểm tra tương ứng vượt qua.

Tài liệu Sống

Giữ các thông số kỹ thuật càng đơn giản và ngắn gọn càng tốt. Sắp xếp các thông số kỹ thuật và phát triển chúng khi công việc tiến triển. Làm cho tài liệu có thể truy cập cho tất cả trong nhóm.

Đặc điểm kỹ thuật theo các bước quy trình mẫu

Hình minh họa cho thấy các bước quy trình trong Đặc tả bằng ví dụ.

Chống mẫu

Anti-pattern là một số mẫu nhất định trong phát triển phần mềm được coi là một phương pháp lập trình tồi. Trái ngược với các mẫu thiết kế, là cách tiếp cận phổ biến đối với các vấn đề chung, đã được chính thức hóa và thường được coi là một thực tiễn phát triển tốt, các mẫu chống thì ngược lại và không được mong muốn

Các mô hình chống lại làm phát sinh nhiều vấn đề khác nhau.

Chống mẫu	Các vấn đề
Không hợp tác	Nhiều giả thiết Xây dựng sai Kiểm tra điều sai Không biết khi mã hoàn thành
Không biết khi mã hoàn thành	Khó duy trì các bài kiểm tra Thông số kỹ thuật khó hiểu Mất sự quan tâm từ các đại diện doanh nghiệp
Ví dụ quá chi tiết hoặc quá tập trung vào giao diện người dùng	Khó duy trì các bài kiểm tra Thông số kỹ thuật khó hiểu Mất sự quan tâm từ các đại diện doanh nghiệp
Đánh giá thấp nỗ lực cần thiết	Các đội nghĩ rằng họ đã thất bại và thất vọng sớm

Giải pháp cho các vấn đề - Chất lượng

Chất lượng có thể được đảm bảo bằng cách giữ đồng hồ trên các mẫu chống. Để giảm thiểu các vấn đề do anti-pattern tạo ra, bạn nên -

Tập hợp lại để xác định bằng cách sử dụng các ví dụ.
Làm sạch và cải thiện các ví dụ.
Viết mã đáp ứng các ví dụ
Tự động hóa các ví dụ và triển khai.
Lặp lại cách tiếp cận cho mọi câu chuyện của người dùng.

Để giải quyết các vấn đề do chống lại các mẫu nghĩa là tuân thủ -

Collaboration.
Đang tập trung vào cái gì.
Tập trung vào Kinh doanh.
Được chuẩn bị.

Hãy để chúng tôi hiểu ý nghĩa của mỗi điều trên.

Cộng tác

Phối hợp -

Những người kinh doanh, nhà phát triển và người kiểm tra đưa ra ý kiến đóng góp từ quan điểm của riêng họ.
Các ví dụ tự động chứng minh rằng nhóm đã xây dựng điều chính xác.
Quá trình này có giá trị hơn chính các bài kiểm tra.

Tập trung vào cái gì

Bạn phải tập trung vào câu hỏi - 'cái gì.' Trong khi tập trung vào 'cái gì' -

Đừng cố gắng bao quát tất cả các trường hợp có thể xảy ra.
Đừng quên sử dụng các loại thử nghiệm khác nhau.
Giữ các ví dụ càng đơn giản càng tốt.
Các ví dụ phải dễ hiểu đối với người sử dụng hệ thống.
Dụng cụ không nên đóng một vai trò quan trọng trong hội thảo.

Tập trung vào kinh doanh

Để tập trung vào công việc kinh doanh -

Giữ đặc điểm kỹ thuật theo ý định kinh doanh.
Bao gồm doanh nghiệp trong việc tạo và xem xét thông số kỹ thuật.
Ẩn tất cả các chi tiết trong lớp tự động hóa.

Được chuẩn bị

Hãy chuẩn bị cho những điều sau -

Lợi ích không rõ ràng ngay lập tức, ngay cả khi các phương pháp thực hành của nhóm được thay đổi.
Giới thiệu SbE là một thách thức.
Yêu cầu thời gian và đầu tư.
Kiểm tra tự động không miễn phí.

Công cụ

Việc sử dụng các công cụ là không bắt buộc đối với Đặc tả theo Ví dụ, mặc dù trong thực tế, một số công cụ có sẵn. Có những trường hợp thành công theo Đặc điểm kỹ thuật bằng Ví dụ ngay cả khi không sử dụng công cụ.

Các công cụ sau hỗ trợ Đặc tả theo Ví dụ:

Cucumber
SpecFlow
Fitnesse
Jbehave
Concordion
Behat
Jasmine
Relish
Speclog

Các nhóm phát triển thường có quan niệm sai lầm rằng BDD là một khung công cụ. Trên thực tế, BDD là một cách tiếp cận phát triển hơn là một khung công cụ. Tuy nhiên, như trong trường hợp của các phương pháp tiếp cận phát triển khác, cũng có các công cụ cho BDD.

Một số Công cụ BDD đang được sử dụng cho các nền tảng và ngôn ngữ lập trình khác nhau. Họ là -

Dưa chuột (khuôn khổ Ruby)
SpecFlow (.NET framework)
Behave (khung Python)
JBehave (khuôn khổ Java)
JBehave Web (khung công tác Java với tích hợp Selenium)
Rau diếp (khung Python)
Concordion (khung Java)
Behat (khung PHP)
Kahlan (khung PHP)
DaSpec (khung JavaScript)
Jasmine (khung JavaScript)
Cucumber-js (khung JavaScript)
Squish GUI Tester (Công cụ kiểm tra BDD GUI cho JavaScript, Python, Perl, Ruby và Tcl)
Spock (khung Groovy)
Yadda (hỗ trợ ngôn ngữ Gherkin cho các khung như Jasmine (JavaScript framework))

Quả dưa chuột

Cucumber là một công cụ miễn phí cho các đặc tả thực thi được sử dụng trên toàn cầu. Cucumber cho phép nhóm phát triển phần mềm mô tả cách phần mềm hoạt động dưới dạng văn bản thuần túy. Văn bản được viết bằng ngôn ngữ dành riêng cho miền có thể đọc được và dùng làm tài liệu, kiểm tra tự động và hỗ trợ phát triển, tất cả được tập hợp thành một định dạng. Bạn có thể sử dụng hơn bốn mươi ngôn ngữ nói khác nhau (tiếng Anh, tiếng Trung, v.v.) với Cucumber.

Dưa chuột - Các tính năng chính

Các tính năng chính của Cucumber như sau:

Dưa chuột có thể được sử dụng cho Thông số kỹ thuật thực thi, Tự động hóa kiểm tra và Tài liệu sống.
Cucumber hoạt động với Ruby, Java, NET, Flex hoặc các ứng dụng web được viết bằng bất kỳ ngôn ngữ nào.
Cucumber hỗ trợ nhiều Thử nghiệm ngắn gọn hơn trong Bảng - tương tự như những gì FIT làm.
Cucumber đã cách mạng hóa Vòng đời phát triển phần mềm bằng cách kết hợp các yêu cầu, kiểm tra tự động và tài liệu thành một thể thống nhất: thông số kỹ thuật thực thi văn bản thuần túy xác thực phần mềm.

SpecFlow

SpecFlow là một Công cụ BDD cho Nền tảng .NET. SpecFlow là một dự án mã nguồn mở. Mã nguồn được lưu trữ trên GitHub.

SpecFlow sử dụng Cú pháp Gherkin cho Các tính năng. Định dạng Gherkin được giới thiệu bởi Cucumber và cũng được sử dụng bởi các công cụ khác. Ngôn ngữ Gherkin được duy trì như một dự án trên GitHub -https://github.com/cucumber/gherkin

Hành xử

Behave được sử dụng cho khung Python.

Behave hoạt động với ba loại tệp được lưu trữ trong thư mục được gọi là “tính năng” -
- làm nổi bật các tệp với các tình huống hành vi của bạn trong đó.
- Thư mục "bước" với triển khai bước Python cho các tình huống.
- Tùy chọn, một số điều khiển môi trường (mã chạy trước và sau các bước, kịch bản, tính năng hoặc toàn bộ trận đấu quay).
Tính năng Behave được viết bằng Gherkin (với một số sửa đổi) và được đặt tên là “name.feature”.
Các thẻ gắn với một tính năng và kịch bản có sẵn trong các hàm môi trường thông qua đối tượng “tính năng” hoặc “kịch bản” được chuyển cho chúng. Trên các đối tượng đó có một thuộc tính được gọi là “thẻ”, là danh sách các tên thẻ được đính kèm, theo thứ tự chúng được tìm thấy trong tệp tính năng.
Các sửa đổi đối với Tiêu chuẩn Gherkin -
- Behave có thể phân tích cú pháp các tệp Gherkin tiêu chuẩn và mở rộng Gherkin để cho phép các từ khóa bước viết thường vì những từ khóa này đôi khi có thể cho phép các thông số kỹ thuật của tính năng dễ đọc hơn

Rau diếp

Xà lách là một công cụ BDD rất đơn giản dựa trên Dưa chuột. Nó có thể thực thi các mô tả chức năng dạng văn bản thuần túy như các bài kiểm tra tự động cho các dự án Python. Rau diếp nhắm đến các nhiệm vụ phổ biến nhất trên BDD.

Concordion

Concordion là một công cụ mã nguồn mở để tự động hóa Đặc tả bằng Ví dụ cho Java Framework.

Mặc dù các tính năng cốt lõi rất đơn giản, nhưng API khung mở rộng mạnh mẽ cho phép bạn thêm chức năng, chẳng hạn như sử dụng bảng tính Excel làm thông số kỹ thuật, thêm ảnh chụp màn hình vào đầu ra, hiển thị thông tin ghi nhật ký, v.v.

Concordion cho phép bạn viết các thông số kỹ thuật bằng ngôn ngữ bình thường bằng cách sử dụng các đoạn văn, bảng và dấu câu thích hợp và Ngôn ngữ có cấu trúc sử dụng Given / When / Then là không cần thiết.

Concordion đã được chuyển sang các ngôn ngữ khác bao gồm -

C # (Concordion.NET)
Python (PyConcordion)
Ruby (Ruby-Concordion)

Cucumber là một công cụ hỗ trợ các thông số kỹ thuật Thực thi, Tự động hóa kiểm tra và Tài liệu sống.

Phát triển theo hướng hành vi mở rộng dựa trên Đặc điểm kỹ thuật theo ví dụ. Nó cũng chính thức hóa các phương pháp hay nhất về Phát triển theo hướng kiểm tra, đặc biệt là quan điểm làm việc từ bên ngoài vào. Công việc phát triển dựa trên các đặc tả thực thi.

Các key features của các thông số kỹ thuật thực thi như sau:

Các thông số kỹ thuật có thể thực thi là -
- Bắt nguồn từ các ví dụ, đại diện cho các hành vi của hệ thống.
- Được viết với sự hợp tác của tất cả những người tham gia vào quá trình phát triển, bao gồm cả doanh nghiệp và các bên liên quan.
- Dựa trên tiêu chí chấp nhận.
Kiểm tra chấp nhận dựa trên các đặc tả thực thi được tự động hóa.
Một ngôn ngữ phổ biến, được chia sẻ được sử dụng để viết các đặc tả thực thi và các bài kiểm tra tự động như vậy -
- Thuật ngữ miền cụ thể được sử dụng trong suốt quá trình phát triển.
- Tất cả mọi người, bao gồm cả khách hàng và các bên liên quan đều nói về hệ thống, các yêu cầu của hệ thống và việc triển khai hệ thống theo cùng một cách.
- Các thuật ngữ tương tự được sử dụng để thảo luận về hệ thống có trong các yêu cầu, tài liệu thiết kế, mã, thử nghiệm, v.v.
- Bất kỳ ai cũng có thể đọc và hiểu yêu cầu và cách tạo thêm yêu cầu.
- Các thay đổi có thể được điều chỉnh dễ dàng.
- Tài liệu trực tiếp được duy trì.

Cucumber giúp thực hiện quá trình này vì nó liên kết các thông số kỹ thuật thực thi với mã thực tế của hệ thống và các bài kiểm tra chấp nhận tự động.

Cách nó thực hiện điều này thực sự được thiết kế để khách hàng và nhà phát triển làm việc cùng nhau. Khi kiểm tra chấp nhận được thông qua, điều đó có nghĩa là đặc điểm kỹ thuật của hệ thống mà nó đại diện đã được thực hiện đúng.

Thử nghiệm chấp nhận dưa chuột điển hình

Hãy xem xét ví dụ sau.

Feature − Sign up

Đăng ký phải nhanh chóng và thân thiện.
Kịch bản - Đăng ký thành công
- New người dùng sẽ nhận được một e-mail xác nhận và được chào đón cá nhân.
- Given Tôi đã chọn để đăng ký.
- When Tôi đăng ký với các chi tiết hợp lệ.
- Then Tôi sẽ nhận được một email xác nhận.
- And Tôi sẽ thấy một tin nhắn chào mừng được cá nhân hóa.

Từ ví dụ này, chúng ta có thể thấy rằng -

Kiểm tra chấp nhận đề cập đến Features.
Các tính năng được giải thích bởi Scenarios.
Các tình huống bao gồm Steps.

Đặc tả được viết bằng ngôn ngữ tự nhiên trong một tệp văn bản thuần túy, nhưng nó có thể thực thi được.

Làm việc của dưa chuột

Cucumber là một công cụ dòng lệnh xử lý các tệp văn bản chứa các tính năng tìm kiếm các tình huống có thể được thực thi trên hệ thống của bạn. Hãy để chúng tôi hiểu cách hoạt động của Cucumber.

Nó sử dụng một loạt các quy ước về cách các tệp được đặt tên và vị trí của chúng (các thư mục tương ứng) để giúp bạn dễ dàng bắt đầu.
Cucumber cho phép bạn giữ các thông số kỹ thuật, kiểm tra tự động và tài liệu ở cùng một nơi.
Mỗi kịch bản là một danh sách các bước mô tả các điều kiện trước, hành động và hậu điều kiện của kịch bản; nếu mỗi bước thực thi mà không có bất kỳ lỗi nào, kịch bản được đánh dấu là đã qua.
Khi kết thúc quá trình chạy, Cucumber sẽ báo cáo có bao nhiêu kịch bản đã vượt qua.
Nếu một cái gì đó không thành công, nó cung cấp thông tin về cái gì không thành công để nhà phát triển có thể tiến bộ.

Trong dưa chuột, Features, Scenariosvà Các bước được viết bằng một Ngôn ngữ được gọi là Gherkin.

Gherkin là tiếng Anh văn bản thuần túy (hoặc một trong hơn 60 ngôn ngữ khác) có cấu trúc. Gherkin rất dễ học và cấu trúc của nó cho phép bạn viết các ví dụ một cách ngắn gọn.

Cucumber thực thi các tệp của bạn có chứa các thông số kỹ thuật thực thi được viết bằng Gherkin.
Cucumber cần các Định nghĩa Bước để dịch Các bước Gherkin văn bản thuần túy thành các hành động sẽ tương tác với hệ thống.
Khi Cucumber thực hiện một bước trong một kịch bản, nó sẽ tìm kiếm một định nghĩa bước phù hợp để thực thi.
Định nghĩa Bước là một đoạn mã nhỏ với một mẫu gắn liền với nó.
Mẫu được sử dụng để liên kết Định nghĩa bước với tất cả các bước phù hợp và mã là những gì Cucumber sẽ thực thi khi nó nhìn thấy một bước Gherkin.
Mỗi bước có kèm theo Định nghĩa bước.
Hầu hết các bước sẽ thu thập thông tin đầu vào và sau đó ủy quyền cho một khuôn khổ dành riêng cho miền ứng dụng của bạn để thực hiện các lệnh gọi trên khuôn khổ của bạn.

Cucumber hỗ trợ hơn một chục nền tảng phần mềm khác nhau. Bạn có thể chọn cách triển khai Cucumber phù hợp với mình. Mọi triển khai Cucumber đều cung cấp chức năng tổng thể giống nhau và chúng cũng có quy trình cài đặt riêng và chức năng dành riêng cho nền tảng.

Lập bản đồ các bước và định nghĩa bước

Chìa khóa của Cucumber là ánh xạ giữa các bước và định nghĩa bước.

Triển khai dưa chuột

Dưới đây là các triển khai Cucumber.

	Ruby / JRuby
	JRuby (sử dụng Cucumber-JVM)
	Java
	Groovy
	.NET (sử dụng SpecFlow)
	JavaScript
	JavaScript (sử dụng Cucumber-JVM và Rhino)
	Áo choàng
	Gosu
	Lua
	PHP (sử dụng Behat)
	Jython
	C ++
	Tcl

Tích hợp khung

Dưới đây là các triển khai Framework.

	Viên ngọc trên tay vịn
	Selen
	PicoContainer
	Khung mùa xuân
	Watir

Gherkin là một ngôn ngữ, được sử dụng để viết Features, Scenarios, and Steps. Mục đích của Gherkin là giúp chúng tôi viết các yêu cầu cụ thể.

Để hiểu ý chúng tôi về các yêu cầu cụ thể, hãy xem xét ví dụ sau:

Khách hàng nên được tránh nhập các chi tiết thẻ tín dụng không hợp lệ.

Đấu với

Nếu khách hàng nhập số thẻ tín dụng không dài chính xác 16 chữ số, khi họ cố gắng gửi biểu mẫu, nó sẽ hiển thị lại với thông báo lỗi cho họ biết số chữ số chính xác.

Cái sau không có sự mơ hồ và tránh được lỗi và dễ kiểm tra hơn nhiều.

Gherkin được thiết kế để tạo ra các yêu cầu cụ thể hơn. Trong Gherkin, ví dụ trên trông giống như:

Feature

Phản hồi khi nhập chi tiết thẻ tín dụng không hợp lệ Feature Definition

Trong quá trình kiểm tra người dùng, chúng tôi đã thấy nhiều người mắc lỗi Tài liệu

Background True for all Scenarios Below

Given Tôi đã chọn một món hàng để mua,

And Tôi sắp nhập số thẻ tín dụng của mình

Scenario - Số thẻ tín dụng quá ngắnScenario Definition

When Tôi nhập một số thẻ dài dưới 16 chữ số

And tất cả các chi tiết khác đều đúng

And Tôi gửi biểu mẫuSteps

Then biểu mẫu nên được hiển thị lại

And Tôi sẽ thấy một thông báo cho tôi biết số chữ số chính xác

Định dạng và cú pháp Gherkin

Tệp Gherkin là Tệp văn bản thuần túy và có phần mở rộng là .feature. Mỗi dòng không trống phải bắt đầu bằng từ khóa Gherkin, theo sau là bất kỳ văn bản nào bạn thích. Các từ khóa là -

Feature
Scenario
Đưa ra, Khi nào, Sau đó, Và Nhưng (Các bước)
Background
Phác thảo kịch bản
Examples
"" "(Chuỗi tài liệu)
| (Bảng dữ liệu)
@ (Thẻ)
# (Bình luận)
*

Đặc tính

Các Featuretừ khóa được sử dụng để mô tả một tính năng phần mềm và để nhóm các tình huống liên quan. Tính năng có ba yếu tố cơ bản:

The keyword – Feature.
The name of the feature, provided on the same line as the Feature keyword.
An optional (but highly recommended) description that can span multiple lines i.e. all the text between the line containing the keyword Feature, and a line that starts with Scenario, Background, or Scenario Outline.

In addition to a name and a description, Features contain a list of scenarios or scenario outlines, and an optional background.

Thông thường đặt tên cho một .featurebằng cách lấy tên của Đối tượng, chuyển nó thành chữ thường và thay thế khoảng trắng bằng gạch dưới. Ví dụ,

feedback_when_entering_invalid_credit_card_details.feature

Để xác định các Tính năng trong hệ thống của bạn, bạn có thể sử dụng cái được gọi là “mẫu tiêm tính năng”.

Để <đạt được một số mục tiêu> với tư cách là <loại người dùng>, tôi muốn có <a feature>

Mô tả

Một số phần của tài liệu Gherkin không phải bắt đầu bằng từ khóa.

Trong các dòng theo sau Tính năng, kịch bản, phác thảo kịch bản hoặc ví dụ, bạn có thể viết bất cứ thứ gì bạn thích, miễn là không có dòng nào bắt đầu bằng từ khóa. Đây là cách để bao gồm Mô tả.

Tình huống

Để thể hiện hành vi của hệ thống, bạn đính kèm một hoặc nhiều kịch bản với mỗi Tính năng. Thông thường, bạn có thể xem 5 đến 20 kịch bản cho mỗi Tính năng để chỉ định hoàn toàn tất cả các hành vi xung quanh Tính năng đó.

Các kịch bản tuân theo mô hình sau:

Mô tả bối cảnh ban đầu
Mô tả một sự kiện
Mô tả một kết quả mong đợi

Chúng tôi bắt đầu với một ngữ cảnh, mô tả một hành động và kiểm tra kết quả. Điều này được thực hiện với các bước. Gherkin cung cấp ba từ khóa để mô tả từng bối cảnh, hành động và kết quả dưới dạng các bước.

Given - Thiết lập bối cảnh
When - Thực hiện hành động
Then - Kiểm tra kết quả

Những từ khóa này cung cấp khả năng đọc của kịch bản.

Example

Scenario - Rút tiền từ tài khoản.

Given Tôi có 100 đô la trong tài khoản của mình.
When Tôi yêu cầu $ 20.
Then $ 20 nên được phân phát.

Nếu có nhiều Given hoặc là When các bước bên dưới nhau, bạn có thể sử dụng And hoặc là But. Chúng cho phép bạn chỉ định các tình huống một cách chi tiết.

Example

Scenario - Nỗ lực rút tiền bằng thẻ bị đánh cắp.

Given Tôi có 100 đô la trong tài khoản của mình.
But thẻ của tôi không hợp lệ.
When Tôi yêu cầu $ 50.
Then thẻ của tôi không nên được trả lại.
And Tôi nên được yêu cầu liên hệ với ngân hàng.

Trong khi tạo kịch bản, hãy nhớ 'mỗi kịch bản phải có ý nghĩa và có thể được thực hiện độc lập với bất kỳ kịch bản nào khác' '. Điều này có nghĩa là -

Bạn không thể có điều kiện thành công của một kịch bản phụ thuộc vào thực tế là một số kịch bản khác đã được thực hiện trước nó.
Mỗi kịch bản tạo bối cảnh cụ thể của nó, thực thi một thứ và kiểm tra kết quả.

Những tình huống như vậy mang lại những lợi ích sau:

Các bài kiểm tra sẽ đơn giản và dễ hiểu hơn.
Bạn chỉ có thể chạy một tập hợp con các kịch bản của mình và bạn không phải lo lắng về việc tập hợp thử nghiệm của mình bị phá vỡ.
Tùy thuộc vào hệ thống của bạn, bạn có thể chạy các thử nghiệm song song, giảm thời gian thực hiện tất cả các thử nghiệm của bạn.

Phác thảo kịch bản

Nếu bạn phải viết kịch bản với nhiều đầu vào hoặc đầu ra, bạn có thể tạo ra một số kịch bản chỉ khác nhau về giá trị của chúng. Giải pháp là sử dụng phác thảo kịch bản. Để viết một dàn ý kịch bản,

Các biến trong các bước phác thảo kịch bản được đánh dấu bằng dấu <và>.
Các giá trị khác nhau cho các biến được đưa ra dưới dạng ví dụ trong bảng.

Example

Giả sử bạn đang viết Tính năng để cộng hai số trên máy tính.

Feature - Thêm.

Scenario Outline: Add two numbers.
Given the input "<input>"
When the calculator is run
Then the output should be <output>"
Examples
| input    | output |
| 2+2      | 4      | 
| 98+1     | 99     |
| 255+390  | 645    |

Phần phác thảo kịch bản luôn được theo sau bởi một hoặc nhiều phần ví dụ, là phần chứa cho một bảng. Bảng phải có hàng tiêu đề tương ứng với các biến trong các bước phác thảo kịch bản. Mỗi hàng bên dưới sẽ tạo một kịch bản mới, điền vào các giá trị biến

SpecFlow là một dự án mã nguồn mở. Mã nguồn được lưu trữ trên GitHub. Các tệp tính năng được SpecFlow sử dụng để lưu trữ tiêu chí chấp nhận cho các tính năng (ca sử dụng, câu chuyện người dùng) trong ứng dụng của bạn được xác định bằng cú pháp Gherkin.

Định dạng Gherkin được giới thiệu bởi Cucumber và cũng được sử dụng bởi các công cụ khác. Ngôn ngữ Gherkin được duy trì như một dự án trên GitHub -https://github.com/cucumber/gherkin

Yếu tố tính năng và SpecFlow

Các tính năng chính của phần tử Tính năng là -

Phần tử tính năng cung cấp tiêu đề cho tệp tính năng. Phần tử tính năng bao gồm tên và mô tả cấp cao của tính năng tương ứng trong ứng dụng của bạn.
- SpecFlow tạo ra một lớp kiểm tra đơn vị cho phần tử tính năng, với tên lớp bắt nguồn từ tên của tính năng.
- SpecFlow tạo các bài kiểm tra đơn vị có thể thực thi từ các kịch bản đại diện cho các tiêu chí chấp nhận.
Tệp tính năng có thể chứa nhiều kịch bản được sử dụng để mô tả các thử nghiệm chấp nhận của tính năng.
- Các kịch bản có một tên và có thể bao gồm nhiều bước kịch bản.
- SpecFlow tạo ra một phương pháp kiểm tra đơn vị cho mỗi kịch bản, với tên phương thức bắt nguồn từ tên của kịch bản.

Nhiều bước kịch bản

Các kịch bản có thể có nhiều bước kịch bản. Có ba loại bước xác định các điều kiện tiên quyết, các hành động hoặc các bước xác minh, tạo nên kiểm tra chấp nhận.

Các loại bước khác nhau bắt đầu bằng Given, When hoặc là Then từ khóa tương ứng và các bước tiếp theo cùng loại có thể được liên kết bằng cách sử dụng And và But từ khóa.
Cú pháp Gherkin cho phép bất kỳ sự kết hợp nào của ba loại bước này, nhưng một kịch bản thường có các khối riêng biệt của Given, When và Then các câu lệnh.
Các bước tình huống được xác định bằng cách sử dụng văn bản và có thể có bảng bổ sung được gọi là DataTable hoặc văn bản nhiều dòng được gọi là đối số DocString.
Các bước kịch bản là cách chính để thực thi bất kỳ mã tùy chỉnh nào nhằm tự động hóa ứng dụng.
SpecFlow tạo ra một cuộc gọi bên trong phương pháp kiểm tra đơn vị cho mỗi bước kịch bản. Cuộc gọi được thực hiện bởi thời gian chạy SpecFlow sẽ thực hiện định nghĩa bước khớp với bước kịch bản.
So khớp được thực hiện trong thời gian chạy, do đó, các thử nghiệm đã tạo có thể được biên dịch và thực thi ngay cả khi ràng buộc chưa được thực hiện.
Bạn có thể bao gồm các bảng và các đối số nhiều dòng trong các bước kịch bản. Chúng được sử dụng bởi các định nghĩa bước và được chuyển dưới dạng đối số bảng hoặc chuỗi bổ sung.

Thẻ

Thẻ là các điểm đánh dấu có thể được gán cho các tính năng và kịch bản. Việc gán thẻ cho một tính năng tương đương với việc gán thẻ cho tất cả các trường hợp trong tệp tính năng. Tên thẻ với thẻ biểu thị @ đứng đầu.

Nếu được hỗ trợ bởi khung kiểm tra đơn vị, SpecFlow tạo danh mục từ các thẻ.
Tên danh mục đã tạo giống với tên của thẻ, nhưng không có @ ở đầu.
Bạn có thể lọc và nhóm các bài kiểm tra sẽ được thực hiện bằng cách sử dụng các danh mục kiểm tra đơn vị này. Ví dụ: bạn có thể gắn thẻ các bài kiểm tra quan trọng bằng @important, sau đó thực hiện các bài kiểm tra này thường xuyên hơn.

Yếu tố nền

Yếu tố ngôn ngữ nền cho phép chỉ định điều kiện tiên quyết chung cho tất cả các tình huống trong một tệp tính năng

Phần nền của tệp có thể chứa một hoặc nhiều bước kịch bản được thực thi trước bất kỳ bước nào khác của tình huống.
SpecFlow tạo ra một phương thức từ các phần tử nền được gọi từ tất cả các bài kiểm tra đơn vị được tạo cho các kịch bản.

Phác thảo kịch bản

Các phác thảo kịch bản có thể được sử dụng để xác định các thử nghiệm chấp nhận theo hướng dữ liệu. Đề cương kịch bản luôn bao gồm đặc tả mẫu kịch bản (kịch bản có phần giữ chỗ dữ liệu sử dụng cú pháp <placeholder>) và một tập hợp các ví dụ cung cấp giá trị cho phần giữ chỗ

Nếu khung kiểm tra đơn vị hỗ trợ nó, SpecFlow sẽ tạo các kiểm tra dựa trên hàng từ các phác thảo kịch bản.
Nếu không, nó tạo ra một phương pháp logic kiểm tra đơn vị được tham số hóa cho một phác thảo kịch bản và một phương pháp kiểm tra đơn vị riêng lẻ cho từng bộ ví dụ.
Để truy xuất nguồn gốc tốt hơn, các tên phương pháp kiểm tra đơn vị được tạo ra được lấy từ tiêu đề phác thảo kịch bản và giá trị đầu tiên của các ví dụ (cột đầu tiên của bảng ví dụ).
Do đó, bạn nên chọn một tham số mô tả và duy nhất làm cột đầu tiên trong tập hợp ví dụ.
Vì cú pháp Gherkin yêu cầu tất cả các cột ví dụ phải có trình giữ chỗ phù hợp trong phác thảo kịch bản, bạn thậm chí có thể giới thiệu một cột tùy ý trong tập ví dụ được sử dụng để đặt tên cho các bài kiểm tra dễ đọc hơn.
SpecFlow thực hiện thay thế trình giữ chỗ như một giai đoạn riêng biệt trước khi khớp với các ràng buộc bước.
Do đó, việc thực hiện và các tham số trong ràng buộc bước không phụ thuộc vào việc chúng được thực thi thông qua một kịch bản trực tiếp hay một phác thảo kịch bản.
Điều này cho phép bạn sau đó chỉ định các ví dụ khác trong các bài kiểm tra chấp nhận mà không cần thay đổi các ràng buộc của bước.

Bình luận

Bạn có thể thêm các dòng nhận xét vào các tệp tính năng ở bất kỳ vị trí nào bằng cách bắt đầu dòng bằng #. Tuy nhiên, hãy cẩn thận, vì các nhận xét trong đặc tả của bạn có thể là một dấu hiệu cho thấy tiêu chí chấp nhận đã được chỉ định sai. SpecFlow bỏ qua các dòng bình luận.