BDD（Behavior Driven Development）はゲームで使用されますか？

私はしばらくの間BDD-Behavior Driven Developmentについて読んでおり、機能をコードに変換することは本当に簡単で便利だと思います。BDDユーザーは、それをTDDが正しく行われたと呼ぶことがよくあります。

BDDは、ビジネス値（またはゲームプレイ値）からコードに至るまで、ソフトウェア設計のためのツールです。

ダンノースがBDDを発表

これ以外にBDDとゲームに関するリソースを知っていますか？

TDDのようなBDD、または（ここにトレンディな開発の流行語のパラダイムを挿入）がどこかのゲーム開発者によって使用されていると言ってもおそらく安全ですが、おそらく彼らは自分が何であるかを知りませんし、BDDが実際に何を意味するのかを必ずしも特定することもできません。 。質問は本当にどれだけ彼らはそれを使用し、どのくらい彼らは持っている、それはあなたには関係するためにそれを使用しますか？

たとえば、私が作業している場合、リンクされた記事でDan Northが示唆しているように、すべてのユニットテスト名は「文」です。もちろん、BDDを使用していると言うだけでは十分ではありませんが、おそらくそれがあなたが本当に気にかけていることでしょうか？

私の意見では、焦点はスタジオでどの流行語を適用するかではなく、全体的にどの生産性と開発プロセスの技法を採用するかではありません。最も生産的なチームは、独断的にではなく、さまざまな「流行語パラダイム」からさまざまな「流行語パラダイム」の技法を組み合わせて一致させていることに気づきます。インターネットの調査によると、特定の流行語パラダイムで構成されています。

これはアジャイルの傾向で最もよく見られます。自分自身を「アジャイルをしている」と特定するチームは、彼らにとって意味のあるアジャイルのビットを有機的に組み込んでいるチームよりも、プロセスについて（皮肉にも）柔軟性がない傾向があります。以前のチームは、ほとんどの場合、私の経験では生産性が低下します。

開発チームは人間で構成されています。人間はマシン内で交換可能な歯車ではありません。彼らは個人として、そして彼ら自身のユニークな組み合わせとして、独自に活動しています。効果的な開発の方法は、{BDD、アジャイル、WhateverIsNext}の型に人間を曲げるのではなく、チームの進行状況を常に再評価し、プロセスの欠陥を解消し、壊れた技術を置き換え、あるものを強化することですワーキング。要するに、「アジャイル（または何でも）であること」ではなく、タイトルの出荷に焦点を当てることです。

それは...ですか？多分。それは低レベルのライブラリにはうまくいくかもしれないが、それは一般的にエンターテインメントソフトウェアには非常に貧弱な適合になるだろうと私は思う。

編集：ここに私の意見の正当性をいくつか示します。

ウィキペディアは、BDDを「ソフトウェアプロジェクトの開発者、QA、非技術者またはビジネス参加者間のコラボレーションを促進する」手法として定義しています。ゲームはほとんどのソフトウェアとは異なり、「非技術的またはビジネス参加者」の特定のニーズを満たすためのツールとして設計されていないが、娯楽のために広く設計されたまとまりのある作品であるため、これはすでに悪い考えのように思えます。「望ましいソフトウェアの振る舞い」に重点が置かれていますが、ゲームは技術的なレベルを除いて「望ましいソフトウェアの振る舞い」を持つことはほとんどありません。コードのその部分をチェックすることには確かにメリットがありますが、エンドユーザーには表示されないためです。

しかし、人間の利害関係者のものを破棄し、BDDを使用してさまざまなコードモジュール間の契約を強制する場合を考えてみましょう。これは、私が見る限り、通常のテスト駆動開発とあまり違いがなく、これも十分に考慮されていません。以下の理由により、ゲームに適しています。

テストは、予期したときに離散イベントが発生したことを確認するのに役立ちます。これは、イベント駆動型プログラミングでうまく機能します。ほとんどのソフトウェアの世界では、アクションが実行され、一部の出力が生成され、アクションと結果が一致することを確認するだけです。ただし、ゲームソフトウェアは通常、シミュレーションであり、アクションは離散的な結果ではなく、世界の状態の継続的な変化をもたらします。隠れているプレーヤーが騒がしい場合は、AIが私を追い詰めていることを確認したいかもしれません。そのため、ノイズが発生した後にAIが「ハンティング」状態にあることを確認するためのテストを作成できます。これは素晴らしいことです。しかし、狩猟がうまくいくことをどうやって知るのですか？あなたはそれを即座にチェックすることはできません-あなたはそれを時間の経過とともにしか観察することができません。

さらに、テストファーストのアプローチは誤った安心感を生み出し、人々はコードが実際よりも優れていると信じるようになります。

def check_dice_roll_in_range():
    d = new Dice()
    assert(d.roll() between 1 and 6)

class Dice:
    def roll():
        return 4

テスト結果は誤検知を引き起こす可能性があるため、コード自体をチェックするという基本的な必要性を免れることはできません。しかし、コード自体が適切にチェックされている場合、テストは二次的な重要性を帯びます。これが、私の意見では、イベント後にバグ修正をテストするためにテストが最もよく使用される理由です。

オブジェクトXとYが一緒に機能するとき、期待どおりの結果が得られるということをテストするメリットは決してないと私は主張しません。問題は、これを確認する最も効果的な方法を使用しているかどうかです。メソッドには、正式な検証、コードレビュー、テストファーストメソッド、テストラストメソッド、従来のQAブラックボックステスト、または単にコードを期待どおりに使用して結果を観察することが含まれます。最後の2つのオプションは、ほとんどの場合、驚くほど効果的です。厳密さを欠くように聞こえますが、ほとんどのバグは通常の使用の過程で発見されるため、人工的なテストで理解するよりも、自然な状況でバグを理解する方が簡単な場合があります。ハーネス。これに加えて、

つまり、要約すると、テスト駆動開発は必ずしもソフトウェアの優れた選択肢ではなく、テストだけではソフトウェアの品質を保証するのに十分ではありません（したがって、開発に費やした時間は、開発者の別の用途と比較する必要があります）。そのゲームは自動化されたテストケースには特に適さず、そのゲームは「ビジネス価値」と「受け入れテスト」に重点を置いた開発方法には特に適さない。

（私の意見に同意しなくても、うまくいけばそれがより良い答えです。）

BDDはあらゆる環境に適していると思います。他の人が言っているように、あなたはソフトウェアを開発しているので、結果としてそれをテストするべきです。文としてテスト名のように言及されたランダムなセマンティクスの一部については、bddが好きです。また、1つのクラスをテストしながら、特定のテストをグループ化することも好きです。

ここで他のメッセージと戦うために、大規模なプロジェクトではテストなしでコードをリファクタリングすることははるかに難しいことを指摘したいと思います。いくつかのコードをリファクタリングすると、すべてが栄光の炎で爆発するかどうかについて、あなたは盲目的に飛んでいます。テストは、物事を早期に把握するのに役立ちます。したがって、テストを書き、失敗し、合格して続行するのに十分なだけコードを記述します。リファクタリングするときも同じことをする必要がありますが、書くのではなくテストを修正します。ほとんどの場合、失敗するテストを実行し、変更する必要があると思われるものを変更し、それでも失敗します。その時点で、他の一部のコードがこの関数/メソッドにまったく異なる方法で依存していることがわかります。その後、テストと結果のコードを修正できます。この種のコードカバレッジがないと、何が壊れているかを見つけようとして何日も偶然見つけてしまいます。

Pragmatic Progammerの本の「契約」について読んでください。テストは、コードコントラクトの達成に役立ちます。このコードはXを実行し、X以外の何も実行せず、Yについて何も実行しないか、Zを実行するように調整しようとはしません。

BDDには他にも理由があります。私にとっての主なものは、とにかく私の仮定を検証するために同じ量のテストを行うので、私はそれを形式化することもできます。

「どのように」という点では、それは実際に環境に依存します。現在、Javaゲームを作成していて、robolectricを使用しています。あなたはいつも何かを「期待する」ように試みるべきです。スパイ/モック/スタブは反対側に同等のものを用意する必要があるため、それほど有用ではないと聞きましたが、特にAPIでは特に選択の余地がない場合があります。ただし、APIの反対側はひどいものではなく、通常はコードが問題であると想定できます。

たとえば、動きをテストしている場合。まあ、「アップ」が押されたときに、ユーザーが何らかの測定によって前進することを期待します。

たとえば、グラフィックスレンダリングをテストしている場合は、実際にテストしているので、あまりテストしないでください。優れたテストフレームワークがこの部分を処理する場合があります。リフレクションは、私がこの種のことについて言うのは簡単なことではありません。バッファなどをチェックする必要があるかもしれません。私は単にあなたが実際に何をしているのかチェックするだけです。キャラクターはここにいます、彼はいくつかの行動の後にそこにいます。

あなたはたくさんの小さな小さな機能/テストを持っているべきであり、一緒にそれらは合計して何か役に立つものになるでしょう。

BDDとは何かについて誤解があるように感じます。BDDは、テスト手法またはプロセスではありません。BDDは開発モデルとプロセスです。それはテストを超えて、プログラミングをはるかに超えています。

そのため、私はこのモデルで動作する主要なAAAスタジオを知りません（世界中にプログラマーとして働いている友人がいます）。他の誰かが指摘したように、どこかのプロジェクトマネージャーまたはチームがBDDに含まれるいくつかのプラクティスを組み込んでいる可能性がありますが、純粋なBDDを適用しているスタジオ（ビジネス価値の定義から、例としての仕様、執筆まで）は知りません。機能ファイル、それらを株主で検証するため、機能ファイルをテストとして自動化するため）。