Pull to refresh

Comments 11

Все просто, если мы имеем дело именно с Unit тестированием, все зависимости подменяются на моки, никаких раздумий. С интеграционными/функциональными тестами уже можно вести разговор о реальных запросах.
Абсолютно согласен с Fesor, в юнит-тестах вы должны были все замокать иначе получается, что вы заодно тестируете Guzzle и чужой API. Тест перестает проверять конкретный юнит, и проверяет всю цепочку.
В жизни так и происходит. Кто-то считает, что это «не его ответственность», а кто-то работает как автор.
По итогу кто-то бегает с подгоревшим пуканом в день релиза, а кто-то катит в отпуск с премией.
в жизни бывает часто и так, что подгорает в день релиза потому что кто-то что-то сломал и укатил с премией в отпуск потому что «это не его ответственность».

p.s. и какую мысль вы хотели донести?
бывает и так :) но покрыл зависимый функционал тестами != сломал. тут совсем не по адресу.
сделал работу не несущую профита, потратил зря время и деньги клиента. В принципе если у вас все зависимости не моки, то это уже интеграционные тесты. Интеграционные тесты которые проверяют взаимодействие одного класса и какой-то библиотеки, это конечно можно делать но как-то странно, обычно более высокоуровневые сервисы так проверяют. Лучше тогда уж сразу писать нормальные функциональные и/или интеграционные тесты, покрывающие код с верхних уровней.
В версии 6.0.1 так же поменялся способ подстановки мок-ответов. Теперь вместо EventSubscriber этим занимаются так называемые хендлеры.
Тест теперь выглядит вот так.
Тест
use GuzzleHttp\Client;
use GuzzleHttp\HandlerStack;
use GuzzleHttp\Psr7\Response;
use GuzzleHttp\Handler\MockHandler;

class APITest extends \PHPUnit_Framework_TestCase
{
    /** @var API */
    protected $api;

    /** @var Client */
    protected $client;

    /** @var MockHandler */
    protected $mockHandler;

    protected function setUp()
    {
        $this->mockHandler = new MockHandler();
        $this->client = new Client(['handler' => HandlerStack::create($this->mockHandler)]);

        $this->api = new API($this->client);
    }

    protected function tearDown()
    {
        unset($this->api, $this->client, $this->mockHandler);
    }

    /**
     * @dataProvider recentTransactionsDataProvider
     *
     * @param string        $response
     * @param int           $expectedCount
     */
    public function testGetRecentTransactions($response, $expectedCount)
    {
        $this->setUpExceptionAssertion($exception);
        $this->mockHandler->append(new Response(200, [], $response));

        $result = $this->api->getRecentTransactions();

        $this->assertInternalType('array', $result);
        $this->assertCount($expectedCount, $result);
    }
}

Скажите, а вы пробовали применить для тестирования php-vcr, или он не подошел?
php-vcr интересный проект, но:
— он бесполезен если разработчики используют TDD/ATDD
— он еще сыроват

В целом есть масса вариантов как можно автоматизировать функциональное тестирование API. Допустим неплохой вариант — документация по API в формате api blueprint + инструменты типа dredd.
Мне кажется, что использовать что-то вроде $isUnitTesting плохая идея в данном случае. Разумнее http-клиент поместить в контейнер зависимостей и затем заменять во время тестирования нужные методы на мокированные. По крайней мере такой подход использовался на практике не раз.
Суть данной статьи конечно не меняется, но всё же.
Увы, часть кода — легаси со старыми принципами, кучей инклудов, глобалов и т.п. Так что приходится от него зависеть.
Sign up to leave a comment.