5

OCMock を使用して内部クラスの依存関係をモックしようとしています (たとえば、私のクラスは NSMutableData を使用し、モック NSMutableData に対して検証しています)。具体的には、ファクトリ メソッドをモックしてモック オブジェクトを返します。

私が知る限り、モック オブジェクトはクラス メソッド モックをクリーンアップしていないか、部分的にしかクリーンアップしていません。これは、同じクラス メソッドを呼び出してしまう可能性のある無関係なテストにかなり悪影響を及ぼしています。

説明するためにローカルで再現できた短い例:

id data1 = [NSMutableData data];    // new instance
id data2 = [NSMutableData data];    // new instance

// mock +data and have it return data1
id mock = [OCMockObject mockForClass:[NSMutableData class]];
[[[[mock stub] classMethod] andReturn:data1] data];

id foo = [NSMutableData data];  // foo == data1 ok that's good

[mock stopMocking];
mock = nil;                     // using ARC so no explicit -release

id bar = [NSMutableData data];  // bar == data1, wait what? shouldn't this be new?

+new をモックすると、問題がさらに悪化することがわかりました。バーを作成する最後の行は、不正な文字列ハッシュまたはスタック オーバーフローのいずれかで爆発します (どちらか一方を一貫して取得する方法がわかりません。両方を見てきました)。

これを回避する方法があることに気づきました。NSMutableData インスタンスを自分のクラスに挿入できますが、これはハードな依存関係ではないため、やり過ぎのように感じます。NSMutableData を作成するクラスにインスタンス メソッドを設定し、モックを注入する代わりにクラスを部分的にモックします。それは問題ありませんが、この特定のケースが機能しない理由を本当に知りたいです。ファクトリ メソッドを実際にスタブ化できれば、内部依存関係のモックはかなり簡単になります。

この問題は、NS クラスに関する特定のものに限定されません (たとえば、NSString のモックに関する制限を認識しています)。私自身のクラスの 1 つで上記の問題を簡単に再現できるからです。

4

0 に答える 0