2014-09-16 5 views
1

Я пытаюсь протестировать некоторые из моих контроллеров с помощью Unit Testing. Но происходит что-то странное. С помощью следующего кода в моем TestCase:Ошибка проверки контроллеров модулей Laravel при использовании нескольких методов

public function test_username_registration_too_short() 
{ 
    $result = $this->action('POST', 'App\\Controllers\\API\\[email protected]', null, [ 
     'username' => 'foo' 
    ]); 
    $this->assertEquals('not_saved', $result->getContent()); 

// $result = $this->action('POST', 'App\\Controllers\\API\\[email protected]', null, [ 
//  'username' => 'foo' 
// ]); 
// $this->assertEquals('not_saved', $result->getContent()); 
} 

public function test_username_registration_too_short_run_2() 
{ 
    $result = $this->action('POST', 'App\\Controllers\\API\\[email protected]', null, [ 
     'username' => 'foo' 
    ]); 
    $this->assertEquals('not_saved', $result->getContent()); 
} 

Когда я запускаю это, первоначальное испытание too_short проходит, но точно такой же код на счете 2 не проходит (это даже удается сохранить пользователя). Но если я поместил тот же самый код дважды в один и тот же метод (что сейчас прокомментировано), он работает отлично? У меня нет ничего в методах setUp или tearDown. И я немного потерялся здесь.

код в контроллере следующее:

$user = new User(Input::all()); 
if($user->save()) 
{ 
    return 'saved'; 
} 
return 'not_saved'; 

ответ

2

Я не собираюсь останавливаться повторяюсь над этим вопросом. Есть similar answer для (несколько) похожих вопросов. TL; DR: don't use unit testing framework for functional/integration testing.

Это область функциональных испытаний, и есть сказочный каркас под названием Бехат. Вы должны делать свои собственные исследования, но по существу, в то время как PHPUnit отлично справляется с тестированием более или менее независимых блоков функциональности, он отсасывает при тестировании больше вещей, таких как полный запрос исполнение. Позже вы начнете испытывать проблемы с сеансом ошибок, неправильно сконфигурированной среды и т. Д., Потому что каждый запрос должен быть выполнен в собственном отдельном пространстве, и вы вынуждаете его делать противоположное. Behat, с другой стороны, работает в очень по-разному, где для каждого сценария (почтовый робот, просмотр несуществующей страницы ) он отправляет новый запрос на сервер и проверяет результат. Он в основном используется для окончательного тестирования всего, что работает вместе , что делает утверждения о конечном результате (объект ответа/html/json).

Если вы хотите проверить свой код надлежащим образом, подумайте об использовании подходящих инструментов для этого. Как только вы узнаете свой путь с Behat, вы полюбите его +, вы можете использовать PHPUnit изнутри Behat, чтобы сделать индивидуальные утверждения.

+2

Но если это не сделано для этого, почему документация Laravel точно показывает, что я делаю? http://laravel.com/docs/testing#refreshing-the-application в моем поиске по сети Я наткнулся на Бехат, но я подумал, хорошо сначала попробуем «Laraval» документально. – Matthijn

+1

Я знаю. Истина заключается в том, что вы можете сказать, что все ваше приложение является единицей в определенном контексте, и вы можете использовать методы тестирования модулей для проведения тестирования. Иногда это приемлемо, но в большинстве случаев это плохая идея. Допустимо было бы, когда ваши действия просты (не имеют много логики, не используйте сеансы, т. Е. Можно запускать несколько раз, не вызывая проблем). В таких ситуациях PHPUnit будет более простым и быстрым решением для запуска ** имитируемых ** запросов. Но чтобы правильно протестировать полные функциональные блоки (запрос/ответ), для этого вам нужен подходящий инструмент. –

+0

Если у вас есть будущие вопросы о Behat/Mink, ознакомьтесь с [соответствующими тегами] (http://stackoverflow.com/questions/tagged/behat+or+mink) или спросите их, есть много поддержки. –

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