単体テストの代わりに積分テスト

Question

私はカスタムコレクションオブジェクトを持っているとしましょう。 removeメソッドの単体テスト（依存関係なし）を作成するにはどうすればよいですか？後でそのアイテムを削除できるようにaddメソッドを呼び出さなければならないため、removeメソッドはaddメソッドに依存します。ほとんどの場合、このカスタムコレクションクラスは、追加されたすべてのコレクションアイテムを含む保護されたプロパティを持ちます。したがって、削除するコレクションアイテムがないため、addメソッドを疑似できません。 addメソッドはおそらく、複数のオブジェクトのプロパティを変更した場合、私は、オブジェクトの集合を使用して、コンストラクタにコレクションアイテムの配列を渡すと、このカスタム・コレクション・オブジェクトの最初のコレクションアイテムとしてこれを使用するが、これが問題になる可能性がある可能性があり

class Item 
{ 
    private $identifier; 

    public function __construct($identifier) 
    { 
     $this->identifier = $identifier; 
    } 

    public function getIdentifier() { return $this->identifier; } 
    ... 
} 

class customCollection 
{ 
    protected $items = []; 
    public function add($item) { 
     $this->items[$item->getIdentifier()] = $item; 
    } 
    public function remove($item) { 
     unset($this->items[$item->getIdentifier()]); 
    } 
    public function getItems() 
    { 
     return $this->items; 
    } 
} 

。ですから、このタスクをどうやって解決するのでしょうか、それとも単なる統合テストですか？フィードバックありがとう！

Answer 1

Itemが十分に簡単な場合は、合併症を気にせずに統合テストを行ってください。最初にItemをテストし、次にcustomCollectionをテストするテストはほとんど作成しないでください。 Itemテストが正常に実行され、customCollectionテストが失敗した場合、そのバグはコレクション内にある可能性が最も高いです。

Itemが非常に複雑な場合は、コレクションで必要なインターフェイスを実装してから、このインターフェイスを簡単に実装してItemをスタブすることができます。その後、Itemと簡単な実装を別々にテストし、その後は簡単な実装で、その後はItemの実装でもテストします。 （でも努力する価値はないと思う）

単体テストと統合テストのポイントは、バグがどこにあるのかを簡単にローカライズすることです。しかし、構造化された統合テストだけで同じことを達成しても問題ありません。