phpunitモックメソッドの異なる引数を持つ複数の呼び出し
異なる入力引数に対して異なるモック期待値を定義する方法はありますか？たとえば、DBというデータベースレイヤークラスがあります。このクラスには「Query（string $ query）」というメソッドがあり、そのメソッドは入力時にSQLクエリ文字列を受け取ります。このクラス（DB）のモックを作成し、入力クエリ文字列に依存するさまざまなQueryメソッド呼び出しに異なる戻り値を設定できますか？
PHPUnit Mockingライブラリー（デフォルト）は、expectsパラメーターに渡されたマッチャーとmethodに渡された制約のみに基づいて、期待値が一致するかどうかを決定します。このため、expectに渡される引数のみが異なる2つのwith呼び出しは、両方とも一致しますが、期待される動作を確認するのは1つだけなので、失敗します。実際の作業例の後の再現事例を参照してください。
問題を解決するには、->at()または->will($this->returnCallback(another question on the subject 。
例：
<?php
class DB {
public function Query($sSql) {
return "";
}
}
class fooTest extends PHPUnit_Framework_TestCase {
public function testMock() {
$mock = $this->getMock('DB', array('Query'));
$mock
->expects($this->exactly(2))
->method('Query')
->with($this->logicalOr(
$this->equalTo('select * from roles'),
$this->equalTo('select * from users')
))
->will($this->returnCallback(array($this, 'myCallback')));
var_dump($mock->Query("select * from users"));
var_dump($mock->Query("select * from roles"));
}
public function myCallback($foo) {
return "Called back: $foo";
}
}
再現：
phpunit foo.php
PHPUnit 3.5.13 by Sebastian Bergmann.
string(32) "Called back: select * from users"
string(32) "Called back: select * from roles"
.
Time: 0 seconds, Memory: 4.25Mb
OK (1 test, 1 assertion)
2つの-> with（）呼び出しが動作しない理由を再現します。
<?php
class DB {
public function Query($sSql) {
return "";
}
}
class fooTest extends PHPUnit_Framework_TestCase {
public function testMock() {
$mock = $this->getMock('DB', array('Query'));
$mock
->expects($this->once())
->method('Query')
->with($this->equalTo('select * from users'))
->will($this->returnValue(array('fred', 'wilma', 'barney')));
$mock
->expects($this->once())
->method('Query')
->with($this->equalTo('select * from roles'))
->will($this->returnValue(array('admin', 'user')));
var_dump($mock->Query("select * from users"));
var_dump($mock->Query("select * from roles"));
}
}
結果
phpunit foo.php
PHPUnit 3.5.13 by Sebastian Bergmann.
F
Time: 0 seconds, Memory: 4.25Mb
There was 1 failure:
1) fooTest::testMock
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-select * from roles
+select * from users
/home/.../foo.php:27
FAILURES!
Tests: 1, Assertions: 0, Failures: 1
ドキュメントの主張として であるため、回避できる場合はat()を使用するのは理想的ではありません
At（）マッチャーの$ indexパラメーターは、指定されたモックオブジェクトのすべてのメソッド呼び出しで、ゼロから始まるインデックスを参照します。このマッチャーを使用する場合は、特定の実装の詳細と密接に結びついた脆弱なテストにつながる可能性があるため、注意してください。
4.1以降では、withConsecutiveなどを使用できます。
$mock->expects($this->exactly(2))
->method('set')
->withConsecutive(
[$this->equalTo('foo'), $this->greaterThan(0)],
[$this->equalTo('bar'), $this->greaterThan(0)]
);
連続した呼び出しで返すようにする場合：
$mock->method('set')
->withConsecutive([$argA1, $argA2], [$argB1], [$argC1, $argC2])
->willReturnOnConsecutiveCalls($retValueA, $retValueB, $retValueC);
私が発見したことから、この問題を解決する最良の方法は、PHPUnitのバリューマップ機能を使用することです。
PHPUnitのドキュメント の例：
class SomeClass {
public function doSomething() {}
}
class StubTest extends \PHPUnit_Framework_TestCase {
public function testReturnValueMapStub() {
$mock = $this->getMock('SomeClass');
// Create a map of arguments to return values.
$map = array(
array('a', 'b', 'd'),
array('e', 'f', 'h')
);
// Configure the mock.
$mock->expects($this->any())
->method('doSomething')
->will($this->returnValueMap($map));
// $mock->doSomething() returns different values depending on
// the provided arguments.
$this->assertEquals('d', $stub->doSomething('a', 'b'));
$this->assertEquals('h', $stub->doSomething('e', 'f'));
}
}
このテストは合格です。ご覧のように：
- 関数がパラメーター「a」と「b」で呼び出されると、「d」が返されます
- 関数がパラメーター「e」および「f」で呼び出されると、「h」が返されます
私が知ることができることから、この機能はPHPUnit 3.6で導入されたため、ほとんどすべての開発で安全に使用できるほど「古い」またはステージング環境および継続的な統合ツール。
Mockery（ https://github.com/padraic/mockery ）がこれをサポートしているようです。私の場合、データベースに2つのインデックスが作成されていることを確認します。
M笑、作品：
use Mockery as m;
//...
$coll = m::mock(MongoCollection::class);
$db = m::mock(MongoDB::class);
$db->shouldReceive('selectCollection')->withAnyArgs()->times(1)->andReturn($coll);
$coll->shouldReceive('createIndex')->times(1)->with(['foo' => true]);
$coll->shouldReceive('createIndex')->times(1)->with(['bar' => true], ['unique' => true]);
new MyCollection($db);
PHPUnit、これは失敗します：
$coll = $this->getMockBuilder(MongoCollection::class)->disableOriginalConstructor()->getMock();
$db = $this->getMockBuilder(MongoDB::class)->disableOriginalConstructor()->getMock();
$db->expects($this->once())->method('selectCollection')->with($this->anything())->willReturn($coll);
$coll->expects($this->atLeastOnce())->method('createIndex')->with(['foo' => true]);
$coll->expects($this->atLeastOnce())->method('createIndex')->with(['bar' => true], ['unique' => true]);
new MyCollection($db);
また、Mockeryの構文はIMHOより優れています。 PHPUnitsの組み込みのモック機能よりも少し遅いようですが、YMMVです。
イントロ
さて、Mockeryには1つのソリューションが用意されているので、Mockeryが好きではないので、Prophecyの代替手段を紹介しますが、最初に MockeryとProphecyの違いについて最初に読んでください。
Long story short：「Prophecyはmessage bindingと呼ばれるアプローチを使用します-メソッドの動作は時間とともに変化しませんが、むしろ他の方法で変更されます。」
カバーする現実世界の問題のあるコード
class Processor
{
/**
* @var MutatorResolver
*/
private $mutatorResolver;
/**
* @var ChunksStorage
*/
private $chunksStorage;
/**
* @param MutatorResolver $mutatorResolver
* @param ChunksStorage $chunksStorage
*/
public function __construct(MutatorResolver $mutatorResolver, ChunksStorage $chunksStorage)
{
$this->mutatorResolver = $mutatorResolver;
$this->chunksStorage = $chunksStorage;
}
/**
* @param Chunk $chunk
*
* @return bool
*/
public function process(Chunk $chunk): bool
{
$mutator = $this->mutatorResolver->resolve($chunk);
try {
$chunk->processingInProgress();
$this->chunksStorage->updateChunk($chunk);
$mutator->mutate($chunk);
$chunk->processingAccepted();
$this->chunksStorage->updateChunk($chunk);
}
catch (UnableToMutateChunkException $exception) {
$chunk->processingRejected();
$this->chunksStorage->updateChunk($chunk);
// Log the exception, maybe together with Chunk insert them into PostProcessing Queue
}
return false;
}
}
PhpUnit Prophecyソリューション
class ProcessorTest extends ChunkTestCase
{
/**
* @var Processor
*/
private $processor;
/**
* @var MutatorResolver|ObjectProphecy
*/
private $mutatorResolverProphecy;
/**
* @var ChunksStorage|ObjectProphecy
*/
private $chunkStorage;
public function setUp()
{
$this->mutatorResolverProphecy = $this->prophesize(MutatorResolver::class);
$this->chunkStorage = $this->prophesize(ChunksStorage::class);
$this->processor = new Processor(
$this->mutatorResolverProphecy->reveal(),
$this->chunkStorage->reveal()
);
}
public function testProcessShouldPersistChunkInCorrectStatusBeforeAndAfterTheMutateOperation()
{
$self = $this;
// Chunk is always passed with ACK_BY_QUEUE status to process()
$chunk = $this->createChunk();
$chunk->ackByQueue();
$campaignMutatorMock = $self->prophesize(CampaignMutator::class);
$campaignMutatorMock
->mutate($chunk)
->shouldBeCalled();
$this->mutatorResolverProphecy
->resolve($chunk)
->shouldBeCalled()
->willReturn($campaignMutatorMock->reveal());
$this->chunkStorage
->updateChunk($chunk)
->shouldBeCalled()
->will(
function($args) use ($self) {
$chunk = $args[0];
$self->assertTrue($chunk->status() === Chunk::STATUS_PROCESSING_IN_PROGRESS);
$self->chunkStorage
->updateChunk($chunk)
->shouldBeCalled()
->will(
function($args) use ($self) {
$chunk = $args[0];
$self->assertTrue($chunk->status() === Chunk::STATUS_PROCESSING_UPLOAD_ACCEPTED);
return true;
}
);
return true;
}
);
$this->processor->process($chunk);
}
}
概要
繰り返しになりますが、予言はもっと素晴らしいです！私の秘trickは、Prophecyのメッセージングバインディングの性質を活用することであり、悲しいことに、非常にまれに$ self = $ this;で始まる典型的なコールバックjavascript地獄コードのように見えますがこのような単体テストを作成する必要があります。これはニースのソリューションだと思います。実際にプログラムの実行を記述するので、デバッグ、フォローは間違いなく簡単です。
ところで：2番目の選択肢がありますが、テストしているコードを変更する必要があります。トラブルメーカーをラップして、別のクラスに移動できます。
$chunk->processingInProgress();
$this->chunksStorage->updateChunk($chunk);
次のようにラップできます。
$processorChunkStorage->persistChunkToInProgress($chunk);
それだけですが、別のクラスを作成したくなかったので、最初のクラスを好みます。