Как проверить конструктор, который устанавливает защищенные свойства? - PullRequest
3 голосов
/ 27 декабря 2011

Ну, я новичок в модульном тестировании (с phpUnit) и только начал тестировать один мой класс.

Фактический конструктор выглядит так:

/**
 * Loads configuration.
 */
function __construct() {

    $config =
        Kohana::$config->load('koffee');

    $this->_table_name = $config->table_name;
    $this->_table_columns = $config->table_columns;

}

Он в основном получает конфигурацию из другого файла и устанавливает его как защищенные свойства для этого объекта.

Вот как выглядит юнит-тест (он еще не закончен и мне нужна помощь):

/**
 * Tests that config is loaded and correct.
 */
function testConfigIsLoadedAndCorrect() {

    $object = new Model_Article();

    $config = Kohana::$config->load('koffee');

    // Compare object's **protected** properties to local `$config`. How?!

}

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

Возможные решения, которые я вижу на данный момент:

  1. Изменить видимость свойств (мне это не нравится),
  2. Добавить так называемые «геттеры» в тест класса I, а не в модульный тест (мне это тоже не нравится);

Возможно, это смешно для вас, но, как я уже сказал, я новичок в юнит-тестах. Любая помощь высоко ценится.

Ответы [ 4 ]

8 голосов
/ 27 декабря 2011

Юнит-тестирование - это примерно единица тестирование. Защищенные участники не являются частью общедоступного интерфейса устройства , и это все, что вам нужно учитывать при написании модульных тестов.

Вы не проверяете внутренние силы юнита, но он работает как положено.

Если вы независимо от этого хотите делать такие вещи, вы можете использовать Сериализация & Docs , приведение к массиву и Отражение & shy; Документы для проверки защищенных / личных свойств объекта или для выполнения защищенных / частных методов объекта.


См. Также: Тестирование частного метода PhpUnit SO Q & A

2 голосов
/ 27 декабря 2011

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

Вы также можете проверить поведение класса, а не данных. Model_Article должна что-то делать с table_name и table_columns, чтобы проверить это поведение. Например, если Model_Article используется для создания HTML-таблицы, то вы можете установить значения конфигурации, создать Model_Article, использовать его для создания HTML, а затем утверждать, что он соответствует жестко закодированной строке, как <table title='name'><tr><th>col1</th><th>col2</th</tr></table>

[править] Вы также можете рассчитывать на внедрение конструктора для передачи table_name и table_columns вместо скрытой зависимости от конфигурации.

2 голосов
/ 27 декабря 2011

Техника, которую я использовал в прошлом, заключалась в создании класса Tester, который предоставляет подходящие методы для тестирования объекта.В этом случае Model_Article_Tester унаследует Model_Article и предоставит метод get.Преимущество здесь в том, что вы выставляете то, что вам нужно для тестирования, не затрагивая производственный код.

0 голосов
/ 07 июля 2017

Вы можете попробовать использовать ReflectionClass :: newInstanceWithoutConstructor

$reflector = new ReflectionClass('Model_Article');
$object = $reflector->newInstanceWithoutConstructor();
...