Instance mocking и implicit constructors

Question

Я пытаюсь использовать TDD для класса, который управляет подключениями к базе данных. Однако

• Я часто развивается от сети, где базы данных доступны
• Я хочу просто проверить классы не возиться с реальными связями, даже SQLite :memory:
• я могу хотеть, чтобы проверить соединения в платформенно-независимом режиме (например, обмен объектами PDO для объектов MySQLi и т. д.). Тем более, что базы данных не все MySQL, некоторые из них - SQLServer.

По существу я хочу сделать это:

class ConnectionManager { 
    ... 
    public function getConnection($name) { 
     $params = $this->lookup($name); 
     return new \PDO($params['spec'], $params['username'], $params['password']); 
    } 
} 

И в моем тестовом бегуна:

class ConnectionManagerTest extends \PHPUnit_Framework_TestCase { 
    public function testGetConnection() { 
     $cxn = new ConnectionManager(); 
     $this->assertNotNull($cxn->getConnection('test')); // or whatever 
    } 
} 

Как-то я хотел бы использовать макет класса PDO. Является ли мой единственный вариант добавить явный параметр в конструктор тестового класса или один из его методов? Я пробовал использовать «Экземпляр издевательства» в соответствии с документацией Mockery, но поскольку я использую автозагрузку, которая приводит к «фатальной ошибке, не может переопределить класс» (duh).

Я бы предпочел не загрязнять контракты с использованием кода, используемого только при тестировании, но это мой единственный вариант?

Спасибо за вашу помощь

Answer 1

Это похоже на случай, когда инъекции зависимости могут помочь вам. В Интернете есть много хороших статей, описывающих этот метод (вот wikipedia overview), и этот предыдущий stack overflow answer дает краткое объяснение этой методики (пример представлен на Java, но он должен объяснить шаблон и быть легко переносимым на другой язык).

Ваш вопрос о том, что «не хочет загрязнять код контрактами, чисто используемыми для тестирования», является интересным. То, что, как я думаю, вы найдете, по мере того, как вы получите больше опыта работы с TDD, заключается в том, что написанный код, который должен легко тестироваться и писать хороший чистый код, по существу является двумя сторонами одной и той же монеты. Одна из тонких возможностей TDD (когда правильная практика) заключается в том, что она ведет вас к хорошему, чистому дизайну, который можно легко вырастить с помощью вашего приложения. Следуя подходу, который ставит тестирование в основу разработки кода, вы на самом деле разрабатываете код с точки зрения клиента, что приводит к более чистым интерфейсам к различным компонентам вашего кода и в конечном итоге делает код, который использует эти интерфейсы более чистым.

Инъекционная инъекция является общепринятой техникой, применяемой при использовании TDD, и является отличной иллюстрацией этих точек. С одной стороны, он эффективен для тестирования, потому что он позволяет вам легко менять компоненты во время тестирования, чтобы вы не могли обращаться к базам данных, имитировать и проверять взаимодействие между компонентами и так далее. Тем не менее, он также поддерживает, как правило, хороший дизайн, поскольку он приводит вас к разработке с низкой и гибкой конструкцией (например, если вы зависите от инъекции доступа к своей базе данных, это довольно просто изменить источник данных из базы данных на некоторые другие технологии).