Как правильно писать тесты PHPUnit под ООП?

Question

[Evgeniy]

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

Когда я пишу классы PHP, то оставляю открытыми(public) только пару методов из 5-10. В таком случае я могу проверять только результат этих нескольких методов в то время как большая часть остается непройденной тестами. Как проверять результат методов private и protected без изменения открытости методов? Возможно само построение класса неверное...

Расскажите пожалуйста, каких правил вы придерживаетесь для создания классов и как создаете тесты под них чтобы проверить все максимально хорошо?

Спасибо

Answer 1

[Виктор Кожухарь]

Вам не надо тестировать приватные методы.
Но как же тогда быть, вы скажете?
Публичные методы используют эти приватные методы, так и проходит тестирование.
Из этого вытекает, что класс должен быть небольшим и выполнять только одну задачу. Поэтому его приватные методы будут всегда задействованы при тестировании публичных.
Но вы скажете, что у вас там в публичных методах обращения к базе данных и внешним API, как же тут быть?
А быть тут просто: все зависимости вашего класса должны включаться в качестве аргументов конструктора, и через использование интерфейсов в аргументах. (Dependency Injection)
Таким образом в тесте все зависимости класса заменяются теми же моками, и вы легко тестируете не просто сферического корня в вакууме (приватный метод), а именно то, что и нужно тестировать: функциональность самого класса, а не его частей, потому что в OOP именно класс является как бы атомом функционала.
Но... если вам всё же таки очень надо, то можно это сделать при помощи рефлексии:
Хорошей практикой является использовать всегда protected вместо private.
Пишете себе такую вот утилиту:

class PHPUnitUtil
{
  public static function callMethod($obj, $name, array $args) {
        $class = new \ReflectionClass($obj);
        $method = $class->getMethod($name);
        // $method->setAccessible(true); // если PHP старше 8.1.0
        return $method->invokeArgs($obj, $args);
    }
}

И используете ее в тестах

$returnVal = PHPUnitUtil::callMethod(
                $this->object,
                '_nameOfProtectedMethod', 
                array($arg1, $arg2)
             );

Есть ещё вариант.

// Оригинальный класс
class Foo {
  protected function stuff() {
    // secret stuff, you want to test
  }
}

// Класс для тестов
class SubFoo extends Foo {
  public function exposedStuff() {
    return $this->stuff();
  }
}

Comments

[Дмитрий]

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

[Виктор Кожухарь]

Дмитрий,
Я о том и написал в первых абзацах. Если использовать Dependency Injection для подключения всех зависимостей, то нам вообще не надо тестировать private методы. А если вдруг стало надо, то лучше задуматься об архитектуре проекта и изменить это...
Использование protected вместо private - это как раз техника на такие вот случаи. Если нам вдруг резко надо будет отнаследоваться с этим методом, то можно будет это сделать вообще без изменений базового класса, что очень приветствуется, когда над проектом работает больше одного человека.
Я большой противник наследования, его использую только в крайних случаях, поэтому лично для меня нет большой разницы между private и protected. А когда как раз вдруг возникает крайняя необходимость в наследовании, то protected тут и выручает.

[Дмитрий]

Виктор Кожухарь, если специально не закладывалась функциональность для наследования, значит автор так и хотел, если подразумевается возможность переопределения метода, то так и делают. имхо.