Là nó? Có lẽ. Ý kiến của tôi là nó sẽ làm cho phần mềm giải trí rất kém phù hợp, mặc dù nó có thể hoạt động tốt cho các thư viện cấp thấp.
EDIT: Đây là một số biện minh cho ý kiến của tôi.
Wikipedia định nghĩa BDD là một kỹ thuật "khuyến khích sự hợp tác giữa các nhà phát triển, QA và những người tham gia phi kỹ thuật hoặc kinh doanh trong một dự án phần mềm." Điều này nghe có vẻ là một ý tưởng tồi bởi vì các trò chơi khác với hầu hết các phần mềm ở chỗ chúng không được thiết kế như một công cụ để đáp ứng nhu cầu cụ thể cho "người tham gia phi kỹ thuật hoặc doanh nghiệp", nhưng là các tác phẩm gắn kết được thiết kế rộng rãi để giải trí. Có một sự nhấn mạnh về "hành vi phần mềm mong muốn" nhưng các trò chơi hiếm khi có "hành vi phần mềm mong muốn" ngoại trừ ở cấp độ kỹ thuật. Chắc chắn có công trong việc kiểm tra phần mã đó, nhưng không phải với người dùng cuối, bởi vì họ sẽ không bao giờ nhìn thấy nó.
Nhưng hãy giả sử rằng bạn muốn loại bỏ những thứ liên quan đến con người và chỉ sử dụng BDD để thực thi hợp đồng giữa các mô-đun mã khác nhau, theo như tôi thấy không khác nhiều so với phát triển dựa trên thử nghiệm thông thường, điều mà tôi cũng cho là kém- phù hợp với các trò chơi, vì lý do sau.
Các xét nghiệm rất hữu ích để kiểm tra các sự kiện rời rạc đã xảy ra khi dự kiến. Điều này hoạt động tốt trong lập trình hướng sự kiện, tức là. hầu hết thế giới phần mềm, nơi một hành động được thực hiện, một số đầu ra được tạo ra, và sau đó bạn chỉ cần xác minh rằng hành động và kết quả khớp với nhau. Tuy nhiên, phần mềm trò chơi thường là một mô phỏng, trong đó một hành động không có kết quả riêng biệt mà thay đổi liên tục trong trạng thái thế giới. Nếu người chơi ẩn của tôi phát ra tiếng động, tôi có thể muốn kiểm tra xem AI có săn lùng tôi không. Vì vậy, tôi có thể tạo một thử nghiệm để đảm bảo rằng AI đang ở trạng thái 'săn mồi' sau khi tiếng ồn được tạo ra, và điều đó thật tuyệt. Nhưng làm thế nào để tôi biết việc săn bắn thậm chí hoạt động? Bạn không thể kiểm tra điều đó ngay lập tức - bạn chỉ có thể quan sát nó theo thời gian.
Ngoài ra, cách tiếp cận thử nghiệm đầu tiên có thể tạo ra cảm giác an toàn sai lầm và khiến mọi người tin rằng mã tốt hơn thực tế.
def check_dice_roll_in_range():
d = new Dice()
assert(d.roll() between 1 and 6)
class Dice:
def roll():
return 4
Vì kết quả kiểm tra có thể cho kết quả dương tính giả, bạn không bao giờ có thể thoát khỏi nhu cầu cơ bản để tự kiểm tra mã. Nhưng nếu bản thân mã được kiểm tra đầy đủ, thử nghiệm sẽ có tầm quan trọng thứ yếu. Đây là lý do tại sao, theo tôi, các bài kiểm tra được sử dụng tốt nhất sau sự kiện này, để kiểm tra sửa lỗi.
Tôi sẽ không tranh luận rằng sẽ không bao giờ có bất kỳ lợi ích nào trong việc kiểm tra rằng, khi các đối tượng X và Y hoạt động cùng nhau, kết quả bạn nhận được là như mong đợi. Vấn đề là liệu bạn có đang sử dụng cách hiệu quả nhất để xác minh điều này hay không. Các phương pháp có thể bao gồm xác minh chính thức, đánh giá mã, phương pháp thử nghiệm đầu tiên, phương pháp thử nghiệm cuối cùng, thử nghiệm hộp đen QA truyền thống hoặc đơn giản là sử dụng mã như mong đợi và quan sát kết quả. Hai tùy chọn cuối cùng có hiệu quả đáng ngạc nhiên trong hầu hết thời gian, bởi vì mặc dù nghe có vẻ thiếu nghiêm ngặt, hầu hết các lỗi được tìm thấy trong quá trình sử dụng thông thường và hiểu một lỗi trong bối cảnh tự nhiên của nó đôi khi có thể dễ dàng hơn là hiểu nó trong thử nghiệm nhân tạo khai thác. Trên hết,
Vì vậy, tóm lại, tôi nghĩ rằng phát triển dựa trên thử nghiệm không nhất thiết phải là sự lựa chọn tuyệt vời cho phần mềm, chỉ riêng các thử nghiệm không bao giờ đủ để đảm bảo chất lượng phần mềm (và do đó thời gian viết chúng phải được so sánh với việc sử dụng thay thế thời gian của nhà phát triển đó), các trò chơi là một kết hợp đặc biệt kém đối với các trường hợp thử nghiệm tự động và các trò chơi là một kết hợp đặc biệt kém đối với các phương pháp phát triển nhằm nhấn mạnh vào 'giá trị kinh doanh' và 'thử nghiệm chấp nhận'.
(Hy vọng rằng đó là một câu trả lời tốt hơn, ngay cả khi bạn không đồng ý với quan điểm của tôi.)