Test-Driven Development là một phương pháp phát triển phần mềm thử nghiệm đầu tiên, có nghĩa là nó yêu cầu viết mã kiểm thử trước khi viết mã thực tế sẽ được kiểm tra. Theo lời của Kent Beck:
Phong cách ở đây là viết một vài dòng mã, sau đó là một bài kiểm tra nên chạy, hoặc thậm chí tốt hơn, để viết một bài kiểm tra không chạy, sau đó viết mã sẽ làm cho nó chạy.
Sau khi tìm ra cách viết một đoạn mã nhỏ, bây giờ, thay vì chỉ viết mã, chúng tôi muốn nhận phản hồi ngay lập tức và thực hành "viết mã một chút, kiểm tra một chút, viết mã một chút, kiểm tra một chút". Vì vậy, chúng tôi ngay lập tức viết một bài kiểm tra cho nó.
Vì vậy, TDD là một phương pháp kỹ thuật cấp thấp, mà các lập trình viên sử dụng để tạo ra mã sạch hoạt động.
Phát triển dựa trên hành vi là một phương pháp được tạo ra dựa trên TDD, nhưng đã phát triển thành một quy trình không chỉ liên quan đến lập trình viên và người thử nghiệm, mà thay vào đó là giao dịch với toàn bộ nhóm và tất cả các bên liên quan quan trọng, kỹ thuật và phi kỹ thuật. BDD bắt đầu từ một vài câu hỏi đơn giản mà TDD không trả lời tốt: tôi nên viết bao nhiêu bài kiểm tra? Tôi thực sự nên kiểm tra những gì và tôi không nên làm gì? Những thử nghiệm nào tôi viết sẽ thực sự quan trọng đối với doanh nghiệp hoặc đối với chất lượng tổng thể của sản phẩm, và đó chỉ là kỹ thuật quá mức của tôi?
Như bạn có thể thấy, những câu hỏi như vậy đòi hỏi sự hợp tác giữa công nghệ và kinh doanh. Các bên liên quan kinh doanh và các chuyên gia tên miền thường có thể cho các kỹ sư biết loại thử nghiệm nào nghe có vẻ hữu ích, nhưng chỉ khi các thử nghiệm là thử nghiệm cấp cao xử lý các khía cạnh kinh doanh quan trọng. BDD gọi các bài kiểm tra giống như doanh nghiệp như vậy, ví dụ về các ứng dụng, các ví dụ như trong các bộ phận khác, cho tôi biết một ví dụ về cách tính năng này hoạt động chính xác, Trực tiếp và bảo lưu từ kiểm tra, kiểm tra kỹ thuật, như xác thực dữ liệu hoặc kiểm tra tích hợp API. Phần quan trọng là trong khi các bài kiểm tra chỉ có thể được tạo bởi các lập trình viên và người kiểm thử, thì các ví dụ có thể được thu thập và phân tích bởi toàn bộ nhóm phân phối của các nhà thiết kế, các nhà phân tích, v.v.
Trong một câu, một trong những định nghĩa tốt nhất về BDD mà tôi đã tìm thấy cho đến nay là BDD nói về những cuộc trò chuyện với các chuyên gia tên miền và sử dụng các ví dụ để có được sự hiểu biết chung về hành vi mong muốn và khám phá những ẩn số. Phần khám phá là rất quan trọng. Khi nhóm phân phối thu thập nhiều ví dụ hơn, họ bắt đầu hiểu về lĩnh vực kinh doanh ngày càng nhiều và do đó họ giảm sự không chắc chắn về một số khía cạnh của sản phẩm mà họ phải đối phó. Khi sự không chắc chắn giảm, sự sáng tạo và tự chủ của đội ngũ giao hàng tăng lên. Chẳng hạn, giờ đây họ có thể bắt đầu đề xuất các ví dụ của riêng mình mà người dùng doanh nghiệp không nghĩ là có thể vì thiếu chuyên môn công nghệ.
Bây giờ, có các cuộc trò chuyện với các chuyên gia kinh doanh và tên miền nghe có vẻ tuyệt vời, nhưng tất cả chúng ta đều biết điều đó thường kết thúc như thế nào trong thực tế. Tôi bắt đầu hành trình của mình với công nghệ là một lập trình viên. Là lập trình viên, chúng tôi được dạy viết mã thuật toán, mẫu thiết kế, trừu tượng. Hoặc, nếu bạn là một nhà thiết kế, bạn được dạy thiết kếTổ chức thông tin và tạo giao diện đẹp. Nhưng khi chúng tôi nhận được công việc cấp đầu vào, chủ lao động của chúng tôi hy vọng chúng tôi sẽ "cung cấp giá trị cho khách hàng." Và trong số những khách hàng đó có thể là, ví dụ ... một ngân hàng. Nhưng tôi không thể biết gì về ngân hàng, ngoại trừ cách giảm số dư tài khoản của mình một cách hiệu quả. Vì vậy, tôi sẽ phải bằng cách nào đó dịch những gì được mong đợi của tôi thành mã ... Tôi sẽ phải xây dựng một cầu nối giữa ngân hàng và chuyên môn kỹ thuật của mình nếu tôi muốn cung cấp bất kỳ giá trị nào. BDD giúp tôi xây dựng một cây cầu như vậy trên nền tảng giao tiếp ổn định giữa đội ngũ giao hàng và các chuyên gia tên miền.
Tìm hiểu thêm
Nếu bạn muốn đọc thêm về BDD, tôi đã viết một cuốn sách về chủ đề này. Viết kỹ thuật tuyệt vời Viết ra khám phá nghệ thuật phân tích các yêu cầu và sẽ giúp bạn tìm hiểu cách xây dựng một quy trình BDD tuyệt vời và sử dụng các ví dụ như một phần cốt lõi của quy trình đó. Cuốn sách nói về ngôn ngữ phổ biến, thu thập các ví dụ và tạo ra cái gọi là thông số kỹ thuật thực thi (kiểm tra tự động) từ các ví dụ về các kỹ thuật giúp các nhóm BDD cung cấp phần mềm tuyệt vời về thời gian và ngân sách.
Nếu bạn quan tâm đến việc mua Thông số kỹ thuật tuyệt vời của Viết, bạn có thể tiết kiệm 39% với mã khuyến mãi 39nicieja2 :)