My opinion is that if you are choosing to use laravel as your framework then your are also choosing to adopt eloquent or query builder for interacting with your database. I therefore consider these to be in-scope of my tests and use the available RefreshDatabase trait to simplify my tests to keep them readable, actual hit a database (even if it is an in memory sqlite db) which catches more bugs than you would think and generally have less brittle tests.
$this->json('post', '/comment',['title => 'test'])
-assertStatus(201);
$this->assertCount(1, Comments::all());
$this->assertDatabaseHas('comments', 'title => 'test');
Super easy/quick to write, readable and tells me a lot about what's working of not in my application. More importantly I know that fundamentally my applications public interface is working.
Mocks, stubs, spies, etc have there place but I rarely use them unless it's for a third party api , etc and even then I normally create a fake version of that class that returns a a sample of that response that I swap out of the service container (with an integration test to actual hit the 3rd party to make sure it's data format hasn't changed)
Is this the correct way to test? From a textbook perspective probably not. Do I sleep soundly at night. I certainly do.
By comparison it does not seam to have any mocking for eloquent. Is there any particular reason for this?
I don't think it's needed, adds complexity to the framework and potentially a barrier to entry for newcomers who want to test.
