5

私は週末に取り組む型を与えられました。それを始める前に、私は本当にいくつかの考えを集めたかった. 私は解決策を探しているのではなく、最良のアプローチ/プラクティスに関するいくつかのアイデアです。

私が行った会話から、BDD --> ATDD (ガーキンのシナリオに関連) --> TDD アプローチを使用する必要があるように思われます。私はただ最善のアプローチを模索しているだけです。

私の現在の考えは、

1) specflow プロジェクトを作成し、ユーザー ストーリーをガーキンに抽出します。

2) GWT 構文を使用してガーキン (シナリオ) で関連する受け入れテストを作成し、[バインディング] クラスで私の ATTD スタイル テストを生成します (「生成」を右クリックします)。

3) gherkin ATDD テストに合格します。

私が抱えている難問は、ガーキン ファイル内の ATTD テストに直接リンクしているテストでは、低レベルの十分なテストが得られないということです。

それで、私は何をしますか？高レベルの ATDD テストを作成し、合格する前に、より深く掘り下げて純粋な TDD テストを作成し、低レベルのオブジェクトを設計しますか?

ええ、私は完全に BDD 方式 (純粋なスタイル) で作業する方法をまだ考えていないので、どのように掘り下げるか疑問に思いました。段階的に作業を進めて 1 つのテストを完了して合格する必要があることを感謝しますが、高レベルの ATDD テストから始めてさらに深くする必要があると感じているため、低レベルのコードが機能するまで高レベルのテストは機能しませんが、従う必要があります。 TDD その低レベルのコードをテストする必要があるため、1 つの単体テストをパスしてからリファクタリングするという原則を既に破っています.....

実際にやらずにこれにアプローチする「方法」を誰かが教えてくれることを願っています。しかし、ここに私に提供された問題があります...（テスターがこれを見た場合、ここで質問したことで失敗する可能性がありますが、仕事を得るよりも学ぶことがより重要です）。はい、私は怒っていることを知っています:-)

また、純粋な TDD テスト用に別のプロジェクトを作成する必要があるかどうかも知りたいです。最適なプロジェクト構造は? 1 つの specflow プロジェクトと .test プロジェクト、クラス ライブラリ、およびランタイム用のコンソール アプリを考えています。

PSこれを手伝ってくれる人は誰でも、私から彼らに恩恵を受けています。抱擁または慈善寄付。または、ここの+1だけがあなたが本当に欲しいものだと思います:-/

最初はグー、じゃんけん

User Story Front
+--------------------------------------------------+
|                                                  |
|     Title: Waste an Hour Having Fun              |
|                                                  |
| As a frequent games player,                      |
| I'd like to play rock, paper, scissors           |
| so that I can spend an hour of my day having fun |
|                                                  |
| Acceptance Criteria                              |
|  - Can I play Player vs Computer?                |
|  - Can I play Computer vs Computer?              |
|  - Can I play a different game each time?        |
|                                                  |
+--------------------------------------------------+

User Story Back
+--------------------------------------------------+
|                                                  |
| Technical Constraints                            |
|                                                  |
| - Doesn't necessarily need a flashy GUI          |
|   (can be simple)                                |
| - Can use any modern language                    |
|                              |
| - Libs / external modules should only be used    |
|   for tests                                      |
| - Using best in industry practices               |
|                                                  |
+--------------------------------------------------+

ゲームを知りませんか？http://en.wikipedia.org/wiki/Rock-paper-scissors

私は縮小版を探しています (最小限の実行可能な製品を考えてください)。データベースなし (つまり、保存されたセッション)、単純なインターフェース - 2 時間または 3 時間分の作業 (トップ) は完全に合理的です。私は本格的なものを探しているのではなく、よく作られた小さなものだけを探しています. これが .NET ではなく Java であり、よりバックエンド指向である場合は、コンソール アプリで間に合わせます。C# で単体テストと適切に分解されたコードを探しています。私が探しているのは、たまたま C# ASP.Net MVC を使用しているコーダーです。

4

2 に答える 2

1

BDD を実行しながら TDD に厳密に従うことは可能ですが、その必要はありませんし、私も従いません。

BDD では、受け入れテストを作成し、単体テストで詳細を追い出すと述べています。したがって、機能の受け入れテストを作成した後、次のいずれかを実行できます。

  • 受け入れテストに合格するために必要なすべてのコードを記述する (その後、リファクタリングする)、または

  • 受け入れテストに合格するために必要なクラスなどを検討し、それぞれを TDD して (つまり、それぞれの単体テストを作成し、それらのテストに合格させ、リファクタリングします)、受け入れテストを実行して、それを確認します。パス（およびリファクタリング）。

これら 2 つの方法のどちらに従うかに関係なく、一方は、単体テストを作成することによって、独自の受け入れテストに値しない要件をテスト駆動します。ただし、最初の方法では、受け入れテストの実装時に作成されたすべてのクラスに戻って単体テストを作成する必要はありません。

私は最初の方法を使用します。

  • 考えやすくなります。事前に多くの設計を行う必要はなく、受け入れテストと単体テストの間でコンテキストを切り替える必要もありません。

  • 受け入れテストに合格するために必要なコードのみを作成します。承認前 (または承認なし) に単体テストを作成すると、間違った推測や余分なコードが発生することが常にわかります。

  • 要件を 2 回テストすることはありません。最小限のテスト スイートは、より高速で保守が容易です。

私が見ることができる2番目の方法の利点は

  • 受け入れテストに合格するために必要な作業が分割されます。(しかし、私が使用しているツールと私が取り組んでいるアプリケーションでは、受け入れテストを一度に実装するだけで問題は通常ありません。 2 回目のパス。)

  • すべてのクラスには常に単体テストがあるため、特定のクラスを変更したときにクラスが壊れていないことを確認するために実行するテストを簡単に見つけることができます。(しかし、いずれにせよ、関連する受け入れテストをすぐに見つけて実行する必要があります。)

プロジェクトの構造に関しては、すべての種類のテストをコードと同じプロジェクト、リポジトリなどに保持する方が良いと常に思っています。見えない、気にしない。

于 2016-02-03T12:11:24.127 に答える