逆にBDD

私はBDDについて読みましたが、1つのことに気付きました。BDDはblab blab blab blahです。 彼には通常の定義はありません。 例えば、ここに書かれています：

BDDは、プログラマー、テスター、アナリスト、マネージャーにソフトウェア開発中の共通の相互作用プロセスを提供するために、TDDの基本的な手法と実践とDDDのアイデアを組み合わせたものです。

すべてが明確ですか？ 私には何もありません。 したがって、BDDに関連する可能性のあることから、私たちが何をしているか、なぜそのことをお伝えします。

機能の計画を開始するとき、次のように「システムの動作」の観点から説明します。

いくつかのバグがあるJiraの問題

すべてのバグが修正されたとき

その後、問題はクローズされます

計画中に、製品所有者と一緒に、顧客（製品所有者）およびテスターと開発者に明らかな量で、これをボードに直接書き込みます：何をする必要があり、それをテストする方法。 実際、これらは、多くの時間を費やすことなく、チーム全体がこのような「短い」形式（および明確ではないことに注意）で記述した要件/テストです。 文書だけでなく、言葉だけ。 これはかなり「ワイルド」なケースであり、必ずしもそれほど単純ではないことを理解していますが、いずれにしても、ビジネスの問題を特定し、詳細に立ち入らずに最も簡潔なソリューションを書き留めようとします。 詳細は後で説明しますが、計画段階で合意するか、POを使用して開発の過程で既に明確にできます（はい、顧客はすぐに質問に答えます）が、文書化もテストもされず、誰も読むことはありません



動作の説明とシステムのドキュメントを混同しないでください。 行動は変化する可能性があります（そして変化します）。 今日、この掘り手は一つのことをし、明日は別のことをします。 上記の動作の説明は、各スプリント/反復ごとに時代遅れになります。これに頼ることはできず、しばらくして機能がどのように配置されるかを知ることができます。 したがって、 関連するすべての機能を説明するシステムドキュメントがあります。 いいえ、そのようなドキュメントはありません。頭とコードにすべてがあります。 そして、これまでのところ、私は不便を経験していません。 そして、頭がバスの下にくるとどうなりますか？ 私もそのような質問をしました。 彼らは私に言った：それは悪いだろうが、ドキュメントが保存されるとは思わない、彼らがすべてを読む可能性は低い、そしてそれがそれほど関連性があり、頭のように答えを与えることができるとは考えにくい。



次にテストについて。 素晴らしいことがあります-キュウリ（および同様のもの： concordion ）。 .Net、Java、Ruby、その他のプログラミング言語のメソッドにテキストの各単純な行（「すべてのバグが修正された」など）をマッピングできます。また、メソッドを再利用できるように正規表現を使用して変数を強調表示することもできます。

また、キュウリのおかげで、すべてのテストは見やすい外観になっており、システムの現在の状態を反映しており、システムのドキュメントのようなものになる可能性があります。

すべてが素晴らしいように見えますが、Cucumberを使用しません。

1. テストメソッド（@ Test
   
   
   
   アノテーションではなくテストAPI）は、プレーンテキストで記述し、正規表現を使用して解析するのが難しい複雑な値/オブジェクト（マップ）を受け入れます。
2. テストメソッドは変数を返し、使用します。たとえば、作成されたエンティティの主キーを返し、このPKは他のメソッドで使用されます。 また、単純なテキスト言語では「変数」のサポートは可能ですが、それでも不便であり、大きなマイナスです。
3. 式を変数として使用します。 たとえば、日付を「最後の日曜日」または「次の月曜日」に設定するさまざまなビルダー。 ところで、可能な限り任意/ランダムのテストデータを生成し、それらに基づいてすべてのチェックを行うため、多くの場合、式と変数を使用します。
4. コンテキスト。 現在のユーザーセッションに関連付けられているほとんどのアクションがあります。 2つの並列セッションを作成する必要がある場合、これは問題を引き起こしませんでした。 キュウリの場合、セッションの表示がある場合とない場合の両方で機能する完全に新しいフレーズ/メソッドを分離する必要があります。
5. データチェック。 これを行うために、ハムクレストを使用し、マッチャーをほんの数個使用するだけで、多様で困難な条件を多数記録できます。 キュウリでは、マッチャーの組み合わせごとに1行のコードで個別のメソッドを選択する必要があります。 そして最悪の場合、マッチャーとテスト値の組み合わせごとに1つの方法があります。
6. リファクタリング コードよりもはるかに多くのテストをリファクタリングします（実は）、IDEはこの点で非常に役立ち、非常に複雑なアクションを自動化します。 単純なテキスト言語をリファクタリングする方法は？ かつて1つのメソッドがあり、その後コードが変更され、異なる変数または異なる名前を持つ2つのメソッドに分割する必要がある場合はどうなりますか。 単純なテキストコードのベース全体でこれを自動的に行うことは可能ですか？

Cucumberを使用した単純なテキストスクリプトの開発に労力を費やすのではなく、Javaで（プロジェクトの他の部分と同様に）記述し、コードを「クリーン」で読みやすい状態に保つことに努力します。

上記はキュウリの批判ではなく、優れた必要なものであり、私たちの場合は解決策よりも多くの問題を引き起こすでしょう（私の意見では、主観的な意見です）。

上記の動作の説明に対応するコード例を考えてみましょう。

 String issueId = issueHelper().createIssue(); List bugIds = new ArrayList(); int numberOfBugs = Random.getNumberBetween(1, 5); while(numberOfBugs>0){ bugIds.add(issueHelper().createBug(issueId)); numberOfBugs--; } for(String bugId : bugIds){ navigator().goto(bugId); workflowHelper().doAction("fixed"); } navigator().goto(issueId); assertThat(getField("status"),is("Closed"));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テストを実行すると、このコードは次を表示します。

任意のパラメーターで課題を作成（新しい課題HR-17の鍵）

問題HR-17にバグを作成（新しいBG-26バグの鍵）

問題HR-17にバグを作成（新しいBG-27バグの鍵）

キーBG-26のページに移動します

固定アクションを実行する

キーBG-27のページに移動します

固定アクションを実行する

キーHR-17でページに移動

ステータスの値が「Closed」フィールドであることを確認します。

このテスト出力は、以前のプロジェクトのキュウリスクリプトに非常によく似ており、アナリスト/マネージャーが読むことができます（チェックしました）。 ログが元のBDD記述とどの程度一致するかについて、一種の「コードレビュー」を行うこともできます。



したがって、「BDD逆も同様」になります。



アナリストや開発者は、コードレビューの過程で何かが気に入らない場合があります。たとえば、「キーでページに移動」メソッドと「アクションを実行」メソッドを1つのメソッドに結合するなど、わずか数クリックでコードをリファクタリングできます。



テストコードには、このようなログが出力する可能性のあるコメントや特別な呼び出しはなく、これは偶然ではないことに気づいたかもしれません。

すべてのログ出力はAspectJテクノロジーに基づいており、メソッド呼び出しをインターセプトしてコードでラップすることができます。 この場合、メソッドの説明をJavaDocからログに出力し、呼び出しが発生したパラメーターの値と、可能であればメソッドによって返された値に置き換えます。

Cucumberテクノロジーと同じことを行いますが、まったく逆です。 ucumberでは、テキスト行から変数を選択する正規表現（またはパターン）を各メソッドに関連付け、ログの出力行で変数を置換するパターンと一致させます。

このすべてのポイントは何ですか？

BDD、ドキュメンテーション、コラボレーションの観点から、抱擁して-私は知りません。

しかし、私は確かに、美しいテストログでは、その意味は次のとおりです。

1. これにより、テストコードの品質が大幅に向上します。 本当です
   
   ただし、メソッド呼び出しの説明を記録し、出力を強制しない場合のみ： log("I did something")
   
   
   
   。 次に、ビジネスコンセプトに対応するメソッドを選択する必要があります。その結果、コードの重複が少なくなり、構造が改善されます。 そして、アナリストは、プログラミングの経験がなくても、これに従うことができます-あなたのコードはビジネスコンセプトで動作するか、奇妙なボタンをクリックします、つまり インターフェースのチェックマークの下位レベルに移動しました。 したがって、テストは短くなり、理解しやすくなります。
2. これにより、テストが「失敗」した理由を理解できます。
   
   さらに、第1レベルのメソッドの呼び出しとしてログを記録できます。 テストスクリプトで記述されたもの、および内部メソッドの呼び出し。 呼び出しだけでなく、すべてのパラメーターと戻り値を使用します。
3. テストの実行内容を把握するために、コードよりもログを理解する方が簡単な場合があります。
   
   私自身も、試して、美しく書いて、リファクタリングするのにこれにショックを受けていますが、それでもしばらくすると、コードが明確にならず、「ロシア語」のログが役立ちます。 まあ、それはまだコードを改善しようとする余地があることを意味します。 ちなみに、BDDの説明を確認すると役立つ場合があります。BDDの説明は、各テストの注釈でボードから書き直します。 これらの説明は、それでもなおよりコンパクトで理解しやすいため、テストレポートに記載されています。 これにより、このような説明とテストスクリプトを分離するのが正しいことを改めて確信させられます。
4. これにより、少なくともいくつかはJavaDocをテストAPIに書き込む必要があります。 これにより、特に複数の人がテストを作成する場合に、テストの作成が単純化されます。 興味深いことに、ucumberを使用している場合、Ctrlキーとスペースバーを使用すると、パラメーターの説明とともに使用可能なメソッドのヒントを取得できますか？ <Ctrl + Space>に移動しました
5. アスペクト指向プログラミングの注意をそらして探索することができます。 将来のアイデアとして： doSomething(getSomething())
   
   
   
   を呼び出すと、 doSomething(getSomething())
   
   
   
   ログがgetSomething()
   
   
   
   メソッドの結果（たとえば5）だけでなく、 getSomething()
   
   
   
   メソッドのJavaDocの説明でgetSomething()
   
   
   
   られることを確認したいこの結果（5）が何を意味し、どこから来たのかは明らかです。 「すべてにうんざりしている」場合は、必ずこれを実行します。

誰かが技術的な詳細に興味がある場合：JavaDocを解析する方法、AspectJを操作する方法、コメントを書く、そしてそれについての別の投稿を準備します。 Excel）、およびこのテーブルの各行に対して呼び出されるテストメソッドを作成することは、Cucumberの仕組みであり、アナリストはそれを好みますが、これには魅力がありません。 どう思いますか？



このf話の教訓は次のとおりです。実験、テストの作成、およびログの作成。