BDD (Phát triển hướng hành vi) có được sử dụng trong các trò chơi không?


9

Tôi đã đọc về BDD - Phát triển hướng hành vi trong một thời gian và tôi thấy việc chuyển đổi các tính năng thành mã rất dễ dàng và hữu ích. Người dùng BDD thường gọi nó là TDD được thực hiện đúng.

BDD là một công cụ để thiết kế phần mềm, từ ngoài vào trong, từ giá trị kinh doanh (hoặc giá trị trò chơi) đến mã.

Dan North giới thiệu BDD

Bạn có biết tài nguyên nào về BDD và các trò chơi khác ngoài điều này không?


Nó trông giống như một sự thích nghi của TDD, và như vậy liên kết đó gần như là một bản sao.
Vịt Cộng sản

Vì BDD là một quy trình được tổ chức tốt để thực hiện TDD, tôi muốn biết nếu có ai đó sử dụng nó, và kinh nghiệm là gì.
MarcoTmp

Không phải câu hỏi đó trả lời câu hỏi của bạn?
Vịt Cộng sản

Không hẳn vậy, vì tôi vẫn không biết người khác sử dụng BDD như thế nào trong các trò chơi.
MarcoTmp

Tôi vẫn cảm thấy về cơ bản TDD được thực hiện theo một phong cách khác.
Vịt Cộng sản

Câu trả lời:


14

Có thể an toàn khi nói rằng BDD, như TDD, hoặc (chèn mô hình từ thông dụng phát triển hợp thời vào đây) được sử dụng bởi một số nhà phát triển trò chơi ở đâu đó, nhưng họ có thể không biết rằng họ cũng không thể xác định được ý nghĩa thực sự của BDD . Câu hỏi đặt ra thực sự là bao nhiêu họ sử dụng nó và bao nhiêu họ sử dụng nó cho nó quan trọng với bạn?

Ví dụ: nơi tôi làm việc, tất cả các tên kiểm tra đơn vị của chúng tôi là "câu" như Dan North gợi ý trong bài viết mà bạn đã liên kết. Điều đó thôi không đủ để nói rằng chúng tôi sử dụng BDD, tất nhiên, nhưng có lẽ đó là điều bạn thực sự quan tâm?

Theo tôi, trọng tâm không nên tập trung vào từ thông dụng nào bạn áp dụng tại phòng thu, mà là kỹ thuật quy trình phát triển và năng suất mà bạn sử dụng tổng thể. Tôi thấy rằng các nhóm làm việc hiệu quả nhất đang pha trộn và kết hợp các kỹ thuật từ nhiều "mô hình từ thông dụng" thay vì cam kết, một cách giáo điều, đến từng chút của học thuyết cứng nhắc mà một nghiên cứu trên internet nói bao gồm một mô hình từ thông dụng cụ thể.

Tôi thấy điều này thường xuyên nhất với xu hướng Agile: các nhóm tự nhận mình là "làm Agile" có xu hướng không linh hoạt hơn (trớ trêu thay) về quy trình so với các nhóm kết hợp hữu cơ các bit của Agile có ý nghĩa với họ. Theo kinh nghiệm của tôi, các đội bóng cũ hầu như luôn kém năng suất.

Một nhóm phát triển được tạo thành từ con người, những người không thể hoán đổi cho nhau trong một cỗ máy. Họ hoạt động độc đáo như cá nhân và là sự kết hợp độc đáo của chính họ. Cách để phát triển hiệu quả không phải là bẻ cong con người của bạn vào khuôn mẫu {BDD, Agile, AnyIsNext} mà là liên tục đánh giá lại cách nhóm đang tiến bộ và bảo vệ những thiếu sót trong quy trình, thay thế các công nghệ bị hỏng và củng cố những thứ đang bị hỏng đang làm việc. Nói tóm lại, để tập trung vào việc vận chuyển một tiêu đề chứ không phải "nhanh nhẹn (hoặc bất cứ điều gì)".


Tất nhiên tôi cần lưu ý rằng tất cả những gì tôi có là bằng chứng giai thoại ở đây viết cho ý kiến ​​của tôi về mối liên hệ giữa việc tuân thủ chặt chẽ quá trình giáo điều và năng suất. Đó chỉ là kinh nghiệm của tôi chứ không phải nghiên cứu khoa học.

1
-1. Cảm ơn ý kiến ​​của bạn. Muốn trả lời câu hỏi?
Jess Telford

+1, câu trả lời hay. @JoshPetrie Sử dụng ít nhất đôi khi sử dụng TDD hay bạn có đo lường phạm vi kiểm tra không? Chỉ thú vị trạng thái thử nghiệm của nhà phát triển trong trò chơi dev.
Ilya Ivanov

1

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.)


-1 từ tôi là tốt; nếu bất cứ điều gì, BDD thậm chí còn phù hợp hơn cho các trò chơi so với những thứ khác. Việc xác định hành vi của một ký tự phản hồi đầu vào thậm chí còn tự nhiên hơn là chỉ định hành vi của dịch vụ web khi trả lời một thông báo XML đã cho.
BlueRaja - Daniel Pflughoeft

1
Phần mềm giải trí vẫn là phần mềm, phải không?
Phổ

Một loạt các ý kiến ​​tốt từ các chuyên gia rất có giá trị, IMHO. Mỗi người có một huy hiệu đại diện cho câu trả lời của họ, vì vậy độc giả có thể nghĩ ra mức độ nặng nề để cân nhắc ý kiến ​​khi được kết hợp với phần còn lại được đăng cho một câu hỏi cụ thể.
Nate

1
Tôi đứng cạnh -1 của tôi, và muốn trả lời một số điều đã được nói: collaboration between developers, QA and [users] [...] sounds like a bad idea - games rarely have 'desired software behaviour'- vâng họ làm: họ cần phải vui vẻ. Cách tốt nhất để biết trò chơi của bạn có thú vị hay không là lắng nghe người chơi. Các nhà phát triển thường bị mù bởi sự sáng tạo của họ (hoặc bởi những khó khăn kỹ thuật) với thực tế rằng trò chơi của họ không có gì thú vị. Người chơi không phải nhà phát triển không gặp phải những vấn đề này.
BlueRaja - Daniel Pflughoeft

2
Đối với thử nghiệm: nếu đó là cách bạn viết bài kiểm tra, thì bạn đang làm sai hoàn toàn . Ví dụ. để kiểm tra Dice, bạn sẽ chuyển vào một đối tượng Ngẫu nhiên giả và đảm bảo Roll()trả về các giá trị chính xác. Bạn sử dụng chính xác các kỹ thuật tương tự để kiểm tra mô phỏng (trò chơi video) mà bạn làm để kiểm tra các ứng dụng thông thường. Kiểm thử đơn vị chỉ có thể kiểm tra các đơn vị - vì vậy bạn chính xác rằng "kiểm tra một mình không bao giờ đủ để đảm bảo chất lượng phần mềm" (đó là lý do tại sao QA vẫn tồn tại). Nhưng điều đó không có nghĩa là chúng ít hữu ích hơn cho các trò chơi video.
BlueRaja - Daniel Pflughoeft

1

Tôi nghĩ rằng BDD là phù hợp trong mọi môi trường. Như những người khác đã đề cập, bạn đang phát triển phần mềm và kết quả là bạn nên kiểm tra nó. Tôi thích bdd cho một số ngữ nghĩa ngẫu nhiên được đề cập như tên kiểm tra như câu. Tôi cũng thích nhóm các bài kiểm tra nhất định với nhau trong khi vẫn có thể kiểm tra 1 lớp.

Để chống lại các thông điệp khác ở đây, tôi muốn chỉ ra rằng trong một dự án lớn hơn, việc tái cấu trúc mã mà không cần kiểm tra là khó khăn hơn. Nếu bạn tái cấu trúc một số mã, bạn sẽ mù quáng về việc liệu mọi thứ sẽ nổ tung trong một vinh quang rực rỡ hay không. Các bài kiểm tra giúp bạn nắm bắt mọi thứ sớm. Vì vậy, bạn viết bài kiểm tra của bạn, thất bại, mã chỉ đủ để vượt qua và tiếp tục. Khi bạn tái cấu trúc, bạn nên làm điều tương tự, nhưng thay vì viết bạn sửa lại bài kiểm tra. Trong hầu hết các trường hợp bạn chạy thử nghiệm, nó sẽ thất bại, bạn thay đổi những gì bạn nghĩ nên thay đổi và VẪN thất bại. Tại thời điểm đó bạn nhận ra rằng một số đoạn mã khác dựa vào hàm / phương thức này theo một cách hoàn toàn khác. Sau đó, bạn có thể sửa bài kiểm tra của mình và mã kết quả. Nếu không có loại bảo hiểm mã đó, bạn sẽ vấp ngã trong nhiều ngày cố gắng tìm nơi bị hỏng,

Hãy đọc về "Hợp đồng" trong cuốn sách của Progammer của Chủ nghĩa thực dụng. Kiểm tra giúp bạn đạt được hợp đồng mã. Mã này làm X và không có gì hơn X và không mong đợi nó làm bất cứ điều gì về Y hoặc cố gắng điều chỉnh nó để làm Z. Nó đảm bảo sự sạch sẽ của mã và hy vọng mọi người sẽ không phải là một kẻ tinh ranh và làm rối tung cơ sở mã.

Có nhiều lý do để BDD. Cái chính đối với tôi là tôi sẽ thực hiện cùng một lượng thử nghiệm để xác nhận các giả định của mình dù sao đi nữa để tôi có thể chính thức hóa nó.

Trên quan điểm "làm thế nào" nó thực sự phụ thuộc vào môi trường của bạn. Tôi đang viết một trò chơi java bây giờ và sử dụng robolectric. Bạn nên luôn luôn cố gắng "mong đợi" một cái gì đó. Tôi đã nghe nói rằng gián điệp / giả / cuống không hữu ích vì bạn cần phải có sự tương đương ở phía bên kia, nhưng đôi khi bạn không có lựa chọn nào đặc biệt là với API. Bạn có thể giả định rằng mặt khác của API không phải là khủng khiếp và đó thường là mã của bạn.

Nếu ví dụ bạn đang thử nghiệm chuyển động. Vâng, bạn mong đợi khi nhấn "Up" mà người dùng di chuyển về phía trước bằng một số phép đo.

Ví dụ, nếu bạn đang kiểm tra kết xuất đồ họa ... thì đừng thử quá nhiều vì bạn có thực sự làm điều đó không? Một khung kiểm tra tốt có thể xử lý phần này cho bạn. Sự phản chiếu không phải là chuyện nhỏ mà tôi muốn nói về những điều này. Bạn có thể cần kiểm tra bộ đệm, v.v. Tôi chỉ đơn giản là kiểm tra xem bạn đang làm gì. Nhân vật ở đây, bây giờ anh ta ở đó sau một số hành động.

Bạn nên có nhiều chức năng / bài kiểm tra nhỏ và cùng nhau chúng sẽ tổng hợp thành thứ gì đó hữu ích.


Cuối cùng, tôi đã nhận thấy rất nhiều người chỉ tình cờ có được hành vi đúng khi mã hóa trò chơi / đồ họa. Kiểm tra kinda ngăn chặn hiệu ứng "nó chỉ kinda hoạt động". Khó khăn hơn nhiều để BIẾT phương trình của bạn sẽ ảnh hưởng đến mọi thứ như thế nào hơn là chỉ sao chép một số mã và đưa ra các giả định.
Parris

BDD không chỉ là về thử nghiệm, mà còn vượt xa hơn thế.
Daniel

0

Tôi cảm thấy có một quan niệm sai lầm về BDD là gì. BDD không phải là một kỹ thuật hoặc quy trình KIỂM TRA. BDD là một mô hình và quy trình phát triển. Nó đi CÁCH vượt quá thử nghiệm và nó đi xa hơn lập trình.

Như vậy, tôi không biết bất kỳ studio AAA lớn nào làm việc với mô hình này (tôi có bạn bè làm việc cho một số người trên khắp thế giới với tư cách là lập trình viên). Như một người khác đã chỉ ra, có thể một số người quản lý dự án hoặc nhóm ở đâu đó kết hợp một số thực hành mà BDD bao gồm, nhưng tôi không biết bất kỳ studio nào áp dụng BDD thuần túy (từ định nghĩa giá trị doanh nghiệp, ví dụ cụ thể, để viết các tệp tính năng, để xác nhận chúng với các cổ đông, để tự động hóa các tệp tính năng dưới dạng thử nghiệm).

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.