2014-02-06 4 views
1

Я пытаюсь протестировать phpunit в моем абстрактном классе, который содержит защищенные методы, которые будут совместно использоваться дочерними элементами. Я читал о частных/защищенных методах, которые нельзя тестировать, потому что это делает код хрупким. В этом случае я не хочу, чтобы эти методы были общедоступным API (хотя это не повредило бы, что-то, что не кажется правильным), и я не хочу тестировать у каждого ребенка, если одно и то же действие родителя хорошо выполняется.Аннотация класс с защищенными методами в phpunit

Таким образом, как пример объясняет больше, я буду стараться размещать простой один

abstract class AbstractAuthenticator 
{ 
    abstract function authenticate(); 

    protected function checkUserPrivilege() 
    { 
     ... code 
    } 

    protected function checkEnvPrivileges() 
    { 
     ... code 
    } 

} 

class BasicAuth extends AbstractAuthenticator 
{ 

    public function authenticate() 
    { 
     $this->checkUserPrivilege(); 
     $this->checkEnvPrivileges(); 
     ... code 
    } 
} 

class AjaxAuth extends AbstractAuthenticator 
{ 

    public function authenticate() 
    { 
     $this->checkUserPrivilege(); 
     $this->checkEnvPrivileges(); 
     ... code 
    } 
} 

Мои вопросы (если я могу сделать больше, чем один), являются:

  • ли этот код для вас смысл?
  • должны быть защищены методы изменены на общественный
  • Если защищенные методы являются публичными, они должны быть проверены вне класса или еще можно назвать в authenticate()
  • Если вы видите это апи (будет все методы помечены как общественность) Wouldn Вы не путаетесь, какие методы вызывать?

Спасибо всем. Я думаю, что этот вопрос сложный и нуждается в некоторой перспективе для изучения, поэтому я прикладываю ваши комментарии.

+0

До сих пор я пробовал http://stackoverflow.com/a/5013441/1358777 предложение с ReflectionClass –

ответ

0

Создайте класс TestAuth и протестируйте защищенные методы в тесте AbstractAuthenticatorTest, который использует его вместо реальных объектов * Auth.

+0

Это способ проверить методы. Реальный вопрос: это правильный способ проверить поведение класса, отличное от его публичного api? после создания трех методов доступа я начал понимать, что действительно важным фактором здесь является обеспечение того, чтобы абстрактный метод проверки подлинности вызывал неявные действия, выполняемые в 'checkUserPrivilege()' и 'checkEnvPrivileges()', и это можно проверить только как утверждения в тестах класса –

+0

Вы должны проверить, что функции checkUserPrivilege и checkEnvPrivileges работают так, как ожидалось, и вызывают их при ожидании. Первый тестируется в тесте AbstractAuthenticatorTest, а второй - во всех тестах класса * Auth. Может быть, я что-то пропустил. привет – gontrollez

+0

Спасибо @gontrollez. У меня есть те же предположения. Я проверю это как лучший ответ –

Смежные вопросы