This terms are usually thrown around and it's nice to make a distinction between both of them. It is no longer a unit test but an integration/functional test, then mocking would be a terrible idea since the latter is meant to test the entire application as a whole. Mocking boils down to the fact that a unit test is meant to be run in isolation so as to properly verify it's functionality.
#Phpunit mocks vs stubs code#
But i'd only recommend this if there is an interface the code is to adhere to. The F in Uncle Bob's rule of unit testing ( F.I.R.S.T) stands for Fast. Logger that writes to the filesystem for example), they always tend to make your tests run extremely slow which is. This stuffs aren't always guaranteed to be available or can prove tedious to set up (an internet connection for example) and even when they are (a Think things like databases, 3rd party API requests and network requests, The major reasons why we mock are Dependency elimination and removal of side effects. To learn more about test doubles read the excellent PHP Test Doubles Patterns.Mocking is simply the process of replacing an object with a fake that can act as a replacement. Most of the time these are separate behaviours that should be covered with distinct test cases. On a final note, I avoid assertions and mock expectations in the same test case. $this->repository->add($user)->shouldHaveBeenCalled() $this->registration = new Registration($repository->reveal()) $this->repository = $this->prophesize(UserRepository::class) Here's an example: private $registration However, PHPUnit has a built in support for prophecy now. Spies are not supported by the classic phpunit mocking framework. There's actually a way to accomplish what you're looking for with another type of test doubles - spies. $this->givenExistingUser() or $this->givenRepositoryWithNoUsers().Īs you noticed, mock expectations (don't confuse them with stubs which are not expectations) are very close to assertions. You can also use helper methods with meaningful names to make your test cases more readable - i.e.
#Phpunit mocks vs stubs how to#
If you find yourself configuring lots of test doubles or writing long test cases, this might mean you have too many collaborators and you should think how to improve your design. It's actually better as your test case has all the context and therefore is more readable. So it's fine to put your test double configurations in the test case. Public function testUserIsAddedToTheRepositoryDuringRegistration() $this->registration = new Registration($repository)
$this->repository = $this->getMock(UserRepository::class) I'd rather instantiate my test doubles in the setup code, assign them to a private properties and configure them in each test case. Mock expectations are very often different for each test case. You don't need to configure your test doubles (stubs/mocks) in the setUp() method.Īctually, I would never configure a mock in test setup code and I would only put very common stubs in there. In short, should we treat expectation declarations as actual assertions and consequently test against them in our test methods? $this->assertMethodCalled($this->mock, 'setSomeValue') ĪssertMethodCalled in not a method exposed by PHPUnit. This might look like that (Mockery): public function setUp()Īnd later at the end of one of the test methods: public function testSoemthing() Would it be good practice to test method call expectations in 'regular' assert. This leads to the situation where we have assertions (assertions + expectations) scattered around the test case class since we end up having actual assertions in the set-up phase of a test case as well as in individual tests. Consequently, making the expectations to be actual assertions. the setUp() method of \PHPUnit_Framework_TestCase.Įxpectations like the ones presented above would break the test if they are not fulfilled. $mock->shouldReceive('doIt')->with(m::anyOf('this','that'))->andReturn($this->getSomething()) Įxpectations like these, are often wired in the set-up phase of a test-suite, e.g. In the Mockery mock object framework, we get the API like this: $stub->expects($this->any())->method('doSomething')->willReturn('foo') in 'vanilla' PHPUnit we can stub a method call and set an expectations like so:
Creating mock classes usually involves configuring method call expectations on the mocks/test doubles.Į.g.
0 kommentar(er)
