0

I have a following class in my PHP code:

<?php
declare(strict_types=1);

use function Http\Response\send;
use Psr\Http\Message\ResponseInterface;

class ResponseSender implements ResponseSenderInterface {
    public function __invoke(ResponseInterface $response) : void {
        send($response);
    }
}

The interface allows other codes to switch how they should "send an HTTP response", and this class simply binds a 3rd-party implementation to that interface.

Is this class too simple to test?

Deduplicator
  • 8,591
  • 5
  • 31
  • 50
Michael Tsang
  • 810
  • 2
  • 7
  • 13
  • 4
    Possible duplicate of [Where is the line between unit testing application logic and distrusting language constructs?](https://softwareengineering.stackexchange.com/questions/322909/where-is-the-line-between-unit-testing-application-logic-and-distrusting-languag) – gnat Nov 15 '18 at 09:38
  • The method in your linked question has a contract that all items in the collection are saved to the data store. However, this method doesn't even have such contract - the contract is that "it calls the 3rd-party send". Is this actually testable? – Michael Tsang Nov 15 '18 at 09:49
  • While the underlying logic of the possible duplicate is different, the principal is the same. What logic is there to test in this class? Same question applies to the possible duplicate. Same answer applies to both questions. – Greg Burghardt Nov 15 '18 at 13:44

1 Answers1

1

Its too simple to unit test. But you should still have integration tests.

Presumably the third party class dosent inplement the interface, hence you need this wrapping interface to be able to replace it with a mock in your unit tests.

So if you try to unit test this, you need another interface and you get into a situation where its 'interfaves all the way down'

If you make an intergration test though, which you should do, it really calls into question what you unit tests of the consuming classes are testing. Why not just integration test them? Why not separate their logic out a different way?

I would forgo this interface and simply integration test an http client for a service against a test http server.

Ewan
  • 70,664
  • 5
  • 76
  • 161
  • 1
    "If you make an intergration test though, which you should do, it really calls into question what you unit tests of the consuming classes are testing. Why not just integration test them? Why not separate their logic out a different way?" I am having a devil of a time understanding this paragraph for some reason... –  Nov 15 '18 at 12:28
  • 2
    im assuming the class is injected into a rest client for some api. so that when you unit test the client you can inject a mock and examine the messages sent. but instead of unit testing the client and integration testing the 'sender: you could just integration test the client – Ewan Nov 15 '18 at 12:55