3

わかりました、TDD プロセス全体を最初から最後まで把握しようと決めました。

私は ASP.NET MVC 2 アプリケーションで簡単なブログを書いており、実装時に機能をテストするための受け入れテストを開始しました。BDD/ATDD フレームワークとして SpecFlow を使用しています。

私は「Growing Object Orientated Systems Guided by Tests」を読んできたので、このように始めました。

私は、本の中でイテレーション ゼロと説明されているポイントで、「ウォーキング スケルトン」を作成しています。

「システムのすべてのコンポーネントをテストする機能の最も薄いスライス」として、ログイン プロセスを開始することにしました。この場合、Web サイト自体とデータベースです。

そのため、ログインについて詳しく説明したストーリーを書きました。最初に書いているシナリオは、ログインに成功することです。

上記のシナリオで与えられたものの1つは

"Given there is a registered user with the username 'TestUser' and password 'TestPassword'"

ただし、このステップをどのように実装するかはわかりません。

明らかに、これは、指定された資格情報を持つユーザーがデータベースに存在する必要があることを意味します。ただし、良い小さなプログラマーのように、パスワードを何らかの方法でハッシュしたいと思います。

私は、それを挿入できるある種の DatabaseHelper クラスを作成することを考えました。ただし、これにはパスワードをハッシュするためのハッシュ コードが含まれており、アプリケーション自体が DRY に違反しているように見える同じハッシュ コードを必要とします。

したがって、ここにはいくつかの関連する質問があります。

  • このステップに苦労しているということは、別の場所から始める必要があるということですか? ログインシステムはサイトの他の部分にとってかなり重要ですが? おそらく、Web サイトとデータベースの両方をテストするのは、機能の最も薄いスライスではないでしょうか?
  • 私と同じ場所から始めるとしたら、どのようにしますか? DRYはまだ気になりませんか？受け入れテストはブラウザを介して外部から機能をテストするため、私にできることはあまりないのでしょうか?

質問がやや漠然としているように思われる場合は、お詫びしなければなりません。TDD をこちらから学ぶ人は誰もいません。また、TDD はパラダイム シフトの 1 つであり、私はまだその「あはは」の瞬間を経験していません。

前もって感謝します。

4

2 に答える 2

3

BDD を行っている場合は、すべてのコンポーネントをテストする最も薄いスライスからではなく、最もリスクの高いコンポーネントをテストする最も薄いスライスから始めることをお勧めしますか?

システムへのアクセス権を持つユーザーは、すでにログインしていると仮定します。ログインは必ずしも危険ではありません。これまでに 15,000 回実行されています。

最初にデータをハードコーディングします。データベースからデータを取得することも、あまり危険ではありません。現実的なデータの例を入手できれば、シナリオに影響を与えずに後でこれをコーディングできます。

システムのどの部分について最もよく知らないかを調べます。シナリオを作成し、システムのそれらの部分について話し合います。最初からシステムを拡張する必要はありません。好きなポイントを選択できます。システムのどの部分が最も不快ですか? 利害関係者を最も不快にさせるのはどの部分ですか?

これらはおそらく、プロジェクトの成功または失敗の原因となるビットです。ログインは後で行うことができ、コードを作成するまでに、人々がログインしたいと思う本当の価値が得られます。

于 2010-07-23T21:24:00.413 に答える
2

そのような登録ユーザーがいないというシナリオから始める方が簡単でしょうか? システムもそれを処理する必要があり、システムが行うことは、データベースに対して「そのようなユーザーはいません」というスタブ以上のものなしで記述できます。

于 2010-07-23T13:39:02.333 に答える