Как тестировать методы, создающие объекты других классов?

Question

[Marcuzy]

Например есть такой класс, где мне нужно протестировать метод someMethod

class Foo
{
	public function someMethod()
	{
		$bar = new Bar;
		$bar->method1();
		$bar->method2();
		$blabla = $bar->getResult();
		//etc
	}
}

Внутри он инстанцирует класс Bar, который может обращаться к "медленным" источникам данных, может внтури иметь связи с другими объектами, поведение которых сложно учитывать, тестируя всего лишь один жалкий метод. Я знаю только один способ - вынести создание объекта класса Bar в отдельный метод класса Foo типа createBar(array $config), благодаря чему метод при написании теста лего мокать. Есть ли другой способ? На практике часто присуствует обращение к моделям ActiveRecord, к примеру поиск по id и прочее, очень неудобно тестировать, не переписывая код.

Answer 1

[matperez]

Разнесите создание инстанса и его использование.

class BarFabric
{
  public function create(array $config = [])
  {
    return new Bar($config);
  }
}
class Foo
{
  protected $barFabric;
  public function __construct(BarFabric $barFabric)
  {
    $this->barFabric = $barFabric;
  }
  public function someMethod()
  {
    $bar = $this->barFabric->create();
    $bar->method1();
    $bar->method2();
    $blabla = $bar->getResult();
    //etc
  }
}

class FooTest
{
  public function testSomeMethod()
  {
    $bar = \Mokery::mock(Bar::class);
    // ... описание поведения для мока
    $factory = \Mokery::mock(BarFactory::class);
    $factory->shouldReceive('create')->andReturn($bar);
    $foo = new Foo($factory);
    $this->assertSomething($foo);
  }
}

О том, как быть с ActiveQuery...

Во первых, выносите логику запроса так же в отдельный класс. Если генерируете новую модель, Gii это может сделать и сам.

class FooQuery extend ActiveQuery
{
    /**
     * @inheritdoc
     * @return Foo[]|array
     */
    public function all($db = null)
    {
        return parent::all($db);
    }

    /**
     * @inheritdoc
     * @return Foo|array|null
     */
    public function one($db = null)
    {
        return parent::one($db);
    }
}

Этот объект передавайте в целевой класс так же как фабрику:

class Bar
{
  protected $query;
  public function __construct(FooQuery $query)
 {
    $this->query = $query;
 }

 public function someMethod()
 {
    $foo = $this->query->where(...)->one();
    $foo->doSomething();
 }
}

Ну а дальше мокайте как и в первом случае

$queryMock = \Mockery::mock(FooQuery::class);
$queryMock->shouldRecieve('where->one')->andReturn($fooMock);

ActiveQuery можно мокать частично, после этого будут выполняться все родные методы, а вот сохранение в базу пропустится.

$fooMock = \Mockery::mock(Foo::class.'[save, update]');
$fooMock->shouldRecieve('save', 'update')->andReturn(true);

Relations можно не подменять вообще. Они прекрасно подставляются через ActiveRecord::populateRelation().

$foo = new Foo();
$foo->populateRelation('bar', new Bar());

Comments

[Marcuzy]

Спасибо. Т.е. нужно использовать DI и ServiceLocator (спасибо qRoC ), погуглив понял что к чему. А вот как быть со статическими методами вроде ActiceRecord::find(), когда для теста логики БД является явно лишней?

[matperez]

Marcuzy: дополнил ответ

[Paulus]

matperez, подскажите пожалуйста, почему Вы инициализируете Bar именно через фабрику?

[matperez]

Paulus: а что именно не понятно? как в приложении это использовать? вот так www.yiiframework.com/doc-2.0/guide-concept-di-cont...

[Paulus]

matperez: не понятно зачем инициализировать зависимость через фабрику, если это можно сделать напрямую в методе, который вызывает конструктор класса, использующего зависимость? Я достаточно часто вижу такой подход, но мне не очень понятна логика, которая за ним стоит.

[matperez]

Paulus: указать в конструкторе зависимость от инстанса, вместо фабрики? ну да, это действительно проще и если других инстансов в процессе создавать не понадобится, то это хороший подход. спасибо! не подумал сразу о таком.

[Paulus]

matperez: спасибо! И тем не менее меня не покидает ощущение, что такой подход чем-то оправдан, тк опять же я его вижу время от времени. :) Но я не могу представить ситуацию из реального мира, где это может быть применено.

[matperez]

Paulus: так а пример я уже привел: в процессе работы может понадобиться создать несколько инстансов, количество которых заранее не известно. часто такое бывает в контроллерах, когда формы под новые модели создаются через js на фронтенде.

[Paulus]

matperez: резонно. про сценарии с js я не думал. спасибо!

Answer 2

[Paulus]

Не следует инициализировать объект Bar в методе someMethod, вместо этого следует использовать паттерн Dependency Injection. Так во-первых создается меньше зависимостей, во-вторых такую конструкцию проще тестировать: в юнит-тесте Вы просто добавляете мок Bar через инъекцию. Я лично в Yii2 предпочитаю инъекцию через конструктор, но это скорее дело вкуса.

Собственно говоря matperez ровно этот паттерн и реализовал.