How unit test service method that use repository method

Question

For service methods that call repository methods to interact with database how could I unit test these service methods?

For example,

public function updateSlideshow($data){
 // do some logic and method calls (I can test those methods,
 // but for this method that call repository ...)
 $r = $this->blockRepo->update($data, $config, $slides);
}

How can I check that this method work correctly or at least send right data to update method?

And what about a scenario that method first fetch data from repository and do logic on it?

• Bernard: Using mocking to mock the repository and its behaviour for testing purposes. A mocking framework will be helpful.
• Andy: You are testing the updateSlideshow, you are not testing the Repository::update method. If you want to test that one, create a specific test only for it. You can also use integration testing to test the whole flow, note that integration tests have side effects.

Answer 1

Assuming you are using dependency injection, then this situation is easily solved. You will be injecting blockRepo into the class/module containing updateSlideshow. So in a live environment, you inject a version of blockRepo that talks to a DB. In a test environment, you inject a version that mocks this behaviour, eg reads/writes to local variables, rather than a DB, allowing you to simulate various DB data states for the various tests.

• Greg Burghardt: An important thing to add is the repository class should implement an interface that your mock can implement. The repository argument in your constructor should have a PHP type hint for the interface.
• David Arno: @GregBurghardt. Ah, thanks. I wasn't sure if PHP supported interfaces, so I tried to make my answer generic. Since it does support them, then I agree 100% with you that interfaces should be used.
• Arash: what would be your assert for service ?

Answer 2

Don't unit test them, at least at first. Use an integration test which brings up an empty database with your DDL loaded, runs this method with some inputs, and asserts on the result data or result behavior.

Having that integration test in place will be a good stepping stone for creating a test double. Code your db-interacting code against an interface which your db class implements. You can then make a test double implementation that uses a Map locally to provide the same interface. That double can be passed along to other pieces of code which depend on database functionality. The integration test you wrote for the full database version can be used to cross-check that the test double exposes correct behavior.

• arisalexis: reminds me of my own question: programmers.stackexchange.com/questions/297944/… if there is almost no logic in the function its better to do integration rather than unit testing in my opinion too