-
-
Save JeffreyWay/5380399 to your computer and use it in GitHub Desktop.
<?php | |
public function testIndex() | |
{ | |
// Mock the Dog class | |
// Expect all() method to be called | |
// and return 'foo' | |
$this->dog->all()->shouldReturn('foo'); | |
// Call /dogs (DB won't be hit) | |
$this->call('GET', '/dogs'); | |
// Make sure view has $dogs var | |
$this->assertViewHas('dogs', 'foo'); | |
} | |
public function testShow() | |
{ | |
// Mock the Dog class | |
// Expect find() method to be called | |
// with argument, 1 | |
// and return 'foo'' | |
$this->dog->find(1)->shouldReturn('foo'); | |
$this->call('GET', '/dogs/1'); | |
$this->assertViewHas('dog', 'foo'); | |
} |
Grr Github bug just lost my reply. Vague idea was along these lines:
I think as a convenience function around the boilerplate then it does it quite well, but I still think it looks possibly misleading. It's hard to tell at a glace whether you're calling all
on an instance variable you've previously set up (maybe in the constructor) called dog
or whether you're doing this mock set-up.
As I said before I think it really comes down to personal preference. If you're the only person working on your code then go for it. If you need people to be able to understand your code who may never have seen this sugar before, then you may be asking for trouble.
Edit: typo
I decided to extend it just a bit to allow people to write the mocks however they wish.
All of the same will achieve the same result:
$this->post->find(1)->shouldReturn('foo');
$this->post->shouldReceive('find')->with(1)->andReturn('foo');
$this->mocked('post')->shouldReceive('find')->with(1)->andReturn('foo');
$this->mock('post')->andExpect('find')->with(1)->toReturn('foo');
I get what you're saying (that's the reason behind my Tweet for second opinions.)
The issue is that the traditional way requires a lot of boilerplate - so much to the point that it scares people away. For example, this code:
...behind the scenes, what is happening is something along the lines of:
To my eyes, the former is much more readable and intuitive. It doesn't require as much visual "decoding" every time I read it. "When /dogs is called, $dog->all() should be triggered, and return foo."