2

私と同僚は議論をしています。私たちはひどいレガシープロジェクトに取り組んでおり、受け入れテストを徐々に追加しています。彼は、私たちがgui / watinで作業を行い、次に低レベルのライブラリを使用してデータベースに直接クエリを実行し、「エンドツーエンド」テストを取得する必要があると考えています。

私たちはNHibernateを使用しており、受け入れテストでアサーションを実行するためにgui/watinを使用してからそれらのnhibernateオブジェクトを使用することを推奨しています。彼はテストでのNHibernateの依存を嫌います。私の主張は、NHibernateオブジェクトに対して統合テストを実行して、意図したとおりにDBで動作していることを確認する必要があるというものでした。その時点で、適切な動作をアサートするための受け入れテストでそれらを使用することにマイナス面はありません。また、彼の低レベルのSQL依存性により、テストが脆弱になり、多くの場合、ビジネスロジックが重複すると思います。

当店での統合テストとは、基本的に、fileRepository / FileSystem Domain-NhibernateObject/Databaseなどの依存関係を持つ単一のコンポーネントを意味します。受け入れテストとは、GUIを介して参加することを意味します。ユニットとは、すべての依存関係がモックアウト/スタブアウトされ、メモリ内に純粋なテストがあり、テスト対象のメソッドのみが実際に実際の作業を実行していることを意味します。デフがオフになっているかどうか教えてください。

とにかく、あなたが私に指摘することができるこの主題についての意見を持つどんな記事/ドキュメント/羊皮紙もいただければ幸いです。

4

1 に答える 1

2

テストを自動化する唯一の理由は、変更を簡単にするためです。それらを変更していなければ、手動テストで逃げることができます。テストをデータベースに関連付けると、データベースの変更がはるかに困難になります。

それらをNHibernateオブジェクトに結び付けることもあまり役に立ちません、私は恐れています！

システムのユーザーは、データベースまたはNHibernateを使用しません。彼らはどのようにして利益を得る（または他の利害関係者に利益を提供する）のですか？彼らはそれがうまく機能していることをどのように知ることができますか？受け入れテストでそれをキャプチャできる場合は、アプリケーションの価値を維持しながら、基盤となるコードとデータを変更できます。誰かがデータからレポートを生成する場合は、同じレポートを生成して、その内容が期待どおりであることを確認してみませんか？データが別のシステムによって読み取られた場合、そのシステムのコピーを取得して、そのシステムがユーザーに何を出力するかを確認できますか？

とにかく、それは私の意見です-受け入れテストを可能な限りビジネス価値に近づけてください-そしてここに私が書いたブログ投稿が役立つかもしれません。また、YahooのBehavior Driven Developmentグループを試すこともできます。このグループには、かなりの経験があります。

ああ、統合テストを実行して（N）Hibernateバインディングが適切であることを確認するのは優れたアイデアです。いくつかのプロジェクトで私たちを救いました。

于 2010-10-07T20:41:27.223 に答える