問題タブ [test-first]

私は MVCStoreFront アプリで Rob Connery の Web キャストを見ていました。

次のようなテストがあります。

私はすべて単体テストに賛成ですが、この形式のテスト ファースト開発が本当に有益かどうか疑問に思うことがあります。たとえば、実際のプロセスでは、コードの上に 3 ～ 4 層があります (ビジネス リクエスト、要件ドキュメント、アーキテクチャ ドキュメント) 、実際に定義されたビジネス ルール (割引価格は価格 - 割引) が誤って定義されている可能性があります。

その場合、単体テストは何の意味もありません。

さらに、単体テストは別の障害点です。

今、テストに欠陥があります。明らかに単純なテストでは大したことではありませんが、複雑なビジネス ルールをテストしているとしましょう。ここで何を得るのですか？

保守開発者がアプリケーションを保守している 2 年間、アプリケーションの寿命を早送りします。ビジネスがルールを変更し、テストが再び失敗し、一部の新人開発者がテストを誤って修正しました...ここで、別の障害点が発生しました。

私が見ているのは、より多くの可能性のある障害点だけであり、実際に有益なリターンはありません.割引価格が間違っていても、テストチームは問題を見つけます.ユニットテストはどのように作業を節約しましたか?

ここで何が欠けていますか？今のところ、TDD を有用なものとして受け入れるのに苦労しているので、TDD を愛するように教えてください。プログレッシブであり続けたいので、私もそうしたいのですが、それは私には意味がありません。

編集: テストが仕様の強制に役立つと何人かの人々が言及し続けています。多くの場合、仕様も間違っていたというのが私の経験ですが、仕様を書くべきではない人によって仕様が書かれている組織で働く運命にあるのかもしれません。

どちらのアイデアも私には非常に似ているように聞こえますが、微妙な違いやまったく同じことが異なる方法で説明されている可能性があります. TDD とテスト ファーストの開発/プログラミングとの関係はどのようなものですか?

私はASP.NETMVCを自分自身に教えるための小さなアプリを書いています。その機能の1つは、Amazon（または他のサイト）で本を検索して「本棚」に追加する機能です。

そこで、IBookSearch（メソッドDoSearchを使用）と呼ばれるインターフェースと、次のような実装AmazonSearchを作成しました。

理想的には、最初にテストを作成して、このTDDスタイルを実行したいと思います。しかし、私は頭を動かすのに苦労していることを告白しなければなりません。

DoSearch（）を実装してアドホックな本を返すFakeSearchを作成することはできますが、現時点ではそれが価値をもたらすとは思いませんか？たぶん後で、本のリストを使用するコードがあるとき。

他に何を最初にテストできますか？私が考えることができる唯一のテストは、クラウドへの呼び出しを（GetAmazonResultsで）モックし、DoSearchがLinq2XML選択を正しく実行して、正しいリストを返すことができることを確認するテストです。しかし、このタイプのテストは、コードを配置した後でしか記述できないように思われるので、何をモックするかを知っています。

あなたたちと女の子がこのテストファーストスタイルをどのように回避するかについてのアドバイスはありますか？

そのため、最近はテスト駆動開発に夢中になっており、tdd を考えながらコードを書くほど、書くべきテストの範囲について決定を下さなければならないように思えます。自分のプロジェクトでどのくらい単体テストを書くべきかについて個人的なポリシーを設定したいと思います.皆さんがどのようなアプローチを取っているかについてアドバイスをいただけないでしょうか.

これが私が現在直面している決定の例です...

私は３クラス...

「GetUser」テスト セットアップが既にある User クラスのデータ アクセス レイヤーがあります。ご覧のとおり、ビジネス ロジックには UserManager.GetTop5() メソッドがあり、DB から取り出したばかりのユーザーの上位 5 つのお気に入りを返します。この方法は非常に単純で、現在、外部リソースや依存関係はありません。

それで私の質問は、失敗する可能性はほとんどありませんが、この「GetTop5」関数ポイントの別のテストを作成していただけないでしょうか?

将来的に機能を拡張する場合に備えて、とにかくテストをセットアップしますか? それとも、ここでのテストは過剰だと思いますか?

数年間、私は qmTest と呼ばれるテスト ツールを使用しており、いくつかの Firebird データベースのテスト駆動型データベース開発を行うことができます。新しい機能 (テーブル、トリガー、ストアド プロシージャなど) が失敗するまでテストを作成し、テストに合格するまでデータベースを変更します。必要に応じて、テストが再び失敗するまでさらに作業を行い、テストが成功するまでデータベースを変更します。機能のテストが完了し、100% の確率で合格したら、それをデータベースの他の一連のテストに保存します。別のテストまたは展開に移る前に、すべてのテストをスイートとして実行して、何も壊れていないことを確認します。テストは他のテストに依存することができ、結果は記録され、ブラウザーに表示されます。

ここには何も新しいことはありません。

当店はMSSQLServerでの標準化を目指しており、データベースの開発にも同じ手順を使用したいと考えています。この種の開発を許可または促進するツールを知っている人はいますか? Team System にはあると思いますが、現時点ではそれを所有していません。

私はスクリプト作成に反対ではありませんが、よりグラフィカルな環境を歓迎します。

助言がありますか？

ASP.NET MVC +FluentNHibernateという独自のプロジェクトを開始します。できるだけテストファーストのアプローチを使いたいです。それで、私は正確にどこから始めますか？データベーススキーマ？ドメインモデル？ドメインモデルクラスをデータベースにマッピングしますか？

このブログ投稿を読んでください-ヘルプ！私はテストでコードを移行/再構築するのがひどいです-最初の方法。私も同じような経験をしたことがあり、もっと広いコミュニティに公開してみようと思いました...

私は現在、StopWatchクラスを実装しようとしています。インターフェイスは次のようなものです。

基本的に、私のアプリは を使用する必要がありますStopWatchが、テストの目的で、StopWatches の結果を人為的に変更する方法があると便利です。そのため、すべてのコード参照IStopWatchを .NET の ではなく にしていますSystem.Stopwatch。

この Test-First を開発しようとしているので、StopWatchクラスのテストを作成した後にのみ、クラスのコードを作成する必要があります。System.Stopwatch.NET のクラスを内部で使用しているため、これから行うテストは単体テストではないことは既に認識しています。

したがって、私の理解では、今できることは次のようなテストだけです。

これを単体テストと同じくらい頻繁に実行できないことはわかっていますが、これについてできることは何もないと思います。私のアプローチは正しいですか、何か不足していますか?

ありがとう

編集

そこで、Quinn351 と Sjoerd の両方のアドバイスに従い、.NET の Stopwatch クラスの代わりに DateTimes を使用するコードを作成しました。

これにより、両方の日付に対して getter/setter を持つ他の実装を作成できるため、GetTimeElapsed() が必要なものを返すようにすることができます。

Stack クラスのテスト ファースト (TDD) を設計しているとします。

このスタックは、サイズ 16 の内部配列を使用して要素を格納します。17 番目の要素を追加する必要があるまでは問題なく動作します。17 番目の要素が必要になるかもしれないので、その機能をスタックに追加することにしたので、その機能を追加しなければならないテストにどのような名前を付けることができるかを考え始めました。それが私の最初の質問の主題になります。

最初に次の形式のものを選択しました。

その後

しかし、少し考えた後、おそらく次のようなものがより適切であるという結論に達しました。

私の推論は、最初のケースではそうしなければならないでしょう。2 つ目は、いつアイテムを追加するかを述べていますが、それを (内部的に) どのように達成しようと考えているかも述べていますが、これは正しくない可能性があります。私の見解では (私が正しいかどうかはわかりません)、私のテストは、SUT が内部でどのように実装されているかではなく、外部との可能な相互作用であるべきです。私は正しいですか？

3番目のオプションが最適であるように見えます.3番目のオプションが最適であると思われます.実装 (後で内部 ArrayList に変更したくなるかもしれません!)。

これは私の2番目の質問につながります.配列を内部的に使用するスタッククラスのすべての単体テストを実行し、それが正常に動作し、期待どおりに動作すると仮定すると、後でリファクタリングして配列をArrayList またはその他の種類のデータ構造? それとも、何らかの方法でテストにそれを反映させる必要がありますか? いいえと思いますが、よくわかりません。

TDD を使用してクラスを実装すると仮定するとStack、Stack クラスの各機能に対して、それを実行する新しいテストを追加する必要があります。

一方、単体テストを実行するときは、クラスが提供するはずの外部動作に焦点を当てる必要があるため、単体テストのセットは、Stack インターフェースの期待されるすべてのコントラクトが満たされていることを確認します。

私の質問は、これらの 2 つの側面をどのように調整するかということです。

たとえばStack、初期サイズが 8 の配列を内部で使用すると仮定すると、ユーザーが 9 番目の項目を挿入したい場合は、配列を大きくする必要があります。そのサイズ変更機能を追加するには、クラス コードをその方向に駆動する少なくとも 1 つのテストが必要です (そうですか?)。

一方、それは、クラスの実際のコントラクトを実行しないユニットテストを追加することになります（または、これは実際にはユニットテストではありませんか？）（ユーザーはスタック) しかし、その実装。

ここにはひねりがあり、解決方法がわかりません。ここで概念を混乱させていますか？

ありがとう

編集

多くのグーグル検索の後、この問題に対処していると思われる次のリンクにたどり着きました: http://stephenwalther.com/blog/archive/2009/04/11/tdd-tests-are-not-unit-tests.aspx