version-control - バージョン管理 - スタブとモック

Question

この質問のために、スタブ、モック、ダミー、偽物などの違いは気にしません。

たとえば、私が他の 1 人とプロジェクトに取り組んでいるとします。私はコンポーネント A に取り組んでおり、彼はコンポーネント B に取り組んでいます。それらは連携して動作するので、私はテストのために B をスタブ化し、彼は A をスタブ化します。ここ。

コンポーネントを一緒にマージするときが来たら、私の A と彼の B から「本物の」ファイルを取得する必要がありますが、偽物はすべて破棄します。開発中、偽物は本物と同じファイル名とクラス名を持つ可能性があります (適切にスタブする方法を学ぶ必要がない限り)。

私の質問は次のとおりです。偽物でバージョン管理を行うための適切な手順は何ですか?コンポーネントはどのように正しくマージされ、偽物ではなく本物を確実に取得しますか? 1 つの方法は、マージを実行し、CONFLICT と表示されることを期待して、半分マージされたファイルからすべての偽のコードを手動で削除することだと思います。しかし、これは面倒で非効率に思えます。

偽物は VC の下に置かれるべきではありませんか? 合併する直前にそれらを引き裂く必要がありますか? これに対する答えが明白または些細な場合は申し訳ありませんが、ここで「推奨される方法」を探しているだけです。

編集：私が気付いていなかったいくつかの追加情報が重要であることが判明しました。私は特に Web 開発について話しているのですが、.NET 開発について話しているのではありません。私の歴史は、その点で人々を誤解させてきたようです。

Answer 1

つまり、基本的にこれが状況です（私が正しく理解していることを確認するため）：

• コンポーネントAの単体テストは、偽のコンポーネントBに対して作成されます。
• コンポーネントBの準備はできていませんでしたが、現在は準備ができています
• 偽物の代わりに実際のコンポーネントBを使用するようにテストをリファクタリングしたい

私は実際にその最後のステップを行うことをお勧めしません。Aの既存の単体テストは、Aをテストすることになっているため、偽のBに対して記述したままにしておきます。AとBの両方の準備ができたので、AとBの間の相互作用をテストする新しい統合テストのセットを記述します。

同じ名前の偽物と実際のクラスについては、実際のクラスではなく、ファイル構造内のどこに偽物を保持するかについて、あなたと他の開発者が合意するいくつかのポリシーで修正します。

Answer 2

フェイクは、単体テストで使用するために、おそらく別のパッケージ/名前空間の下で、ソース管理にある必要があります。両方の実際のコンポーネントを使用する統合テストを行いますが、単体テストは分離したままにします。

実稼働コードはインターフェイスまたは抽象基本クラスを参照し、実装を挿入して、テスト用に偽物を使用し、実物には実稼働クラスを使用できるようにする必要があります。

Answer 3

.gitignoreソース管理にファイルを含めないようにする git 用のファイルがあります。

また、可能であれば動的モックを使用する必要があります。.NET の場合、Rhino.Mock や Moq のようなものを使用すると、ファイルや偽物を保持する代わりに、プログラムでモックを作成できます。