3

私たちは他の開発者が使用するフレームワークを構築しており、今のところ多くの TDD プラクティスを使用しています。どこにでもインターフェースがあり、インターフェースを模擬するよく書かれた単体テストがあります。

ただし、入力クラスのプロパティ/メソッドの一部を内部にする必要があり、フレームワーク ユーザーには表示されないようにする必要があります (オブジェクト Id など)。問題は、インターフェイスがアクセシビリティを記述していないため、これらのフィールド/メソッドをインターフェイスに配置できないことです。

我々は出来た：

  1. メソッドの最初の行で引き続きインターフェイスとアップキャストを使用しますが、それはインターフェイスの目的を無効にしているようです。
  2. クラスを入力パラメーターとして使用する -すべてがインターフェイスでなければならないという TDD ルールを破る
  3. パブリック インターフェイスと内部インターフェイスの間で何らかの変換を行う別のレイヤーを提供する

これに対処するための既存のパターン/アプローチはありますか? TDDの人々は何をすべきだと言っていますか?

4

3 に答える 3

4

まず、すべてがインターフェースでなければならないという一般的な TDD ルールはありません。これは、すべてのTDDerが実践しているわけではない特定のスタイルから来ています. http://martinfowler.com/articles/mocksArentStubs.htmlを参照してください。

次に、 public と publishedの二分法を経験しています。私たちのチームは、API ドキュメントに表示される @Published アノテーションを導入することで、この問題を「解決」しました。私の知る限り、Eclipseは命名規則を使用しています。残念ながら、この問題に対する本当に良い解決策はわかりません。

于 2008-11-01T21:14:57.513 に答える
2

モックアップ オブジェクトでこれらの内部メソッドを複製できる必要があります。そして、実際のオブジェクトがそれらを呼び出すのと同じ方法でそれらを呼び出します。次に、テストする必要があるプライベート メソッドに依存するパブリック メソッドに単体テストを集中させます。これらの内部メソッドが他のオブジェクトを呼び出しているか、多くの作業を行っている場合は、設計のリファクタリングが必要になる場合があります。

幸運を。

于 2008-10-29T20:44:20.733 に答える
0

クラスに依存性注入を持たせたいようですね。スタックオーバーフローも検索してください。次に、コンストラクター内またはセッターを介して選択して、この Id を設定できます。

[1l

于 2008-10-29T09:18:32.443 に答える