Как проверить перенаправление авторизации с Laravel?

Question

Я проверил вручную сценарий:

Администратор Пользователи могут перейти на раздел /codes сайта. Обычные пользователи перенаправляются (302) обратно на /dashboard и имеют сообщение Sorry you are not allowed there, когда они отправляются на /qr.

Ручное тестирование проходит, но тестирование laravel терпит неудачу.

Я использую laravel 5.1

тест для пользователя с правами администратора:

public function testAdminViewCodes() 
    { 
     //create an admin user 
     $user = factory(App\User::class, 'admin')->create(); 

     $this->actingAs($user) 
      ->visit('/codes') 
      ->seePageIs('/codes') 
      ->see('Codes'); 
    } 

испытание для обычного пользователя:

public function testNormalViewCodesFail() 
    { 
     //create a normal user 
     $normal_user = factory(App\User::class)->create(); 

     //TODO: Fix this failing test FFS 

     $this->actingAs($normal_user) 
      ->visit('/qr') 
      ->seePageIs('/dashboard') 
      ->see('Sorry you are not allowed there'); 
} 

результаты испытаний;

There was 1 failure: 

1) AdminTest::testNormalViewQRCodesFail 
Did not land on expected page [http://localhost/dashboard]. 

Failed asserting that two strings are equal. 
--- Expected 
+++ Actual 
@@ @@ 
-'http://localhost/dashboard' 
+'http://localhost/codes' 

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

$factory->define(App\User::class, function (Faker\Generator $faker) { 
    return [ 
     'email' => $faker->email, 
     'password' => bcrypt(str_random(10)), 
     'remember_token' => str_random(10), 
     'is_admin' => false, 
    ]; 
}); 

$factory->defineAs(App\User::class, 'admin', function ($faker) use ($factory) { 
    $user = $factory->raw(App\User::class); 

    return array_merge($user, ['is_admin' => true]); 
}); 

Мои извинения за то, как долго этот вопрос, но есть еще один pertanent вопрос. Я использую middleware, чтобы проверить, является ли пользователь администратора:

<?php 

namespace RMS\Http\Middleware; 

use Closure; 

class IsAdminMiddleware 
{ 
    /** 
    * Handle an incoming request. 
    * 
    * @param \Illuminate\Http\Request $request 
    * @param \Closure $next 
    * @return mixed 
    */ 
    public function handle($request, Closure $next) 
    { 
     if (app()->env === 'testing') { 
      return $next($request); 
     } 

     if (! $request->user()->isAdmin()) { 
      return redirect()->route('dashboard') 
       ->with('message', 'Sorry you are not allowed there'); 
     } 

     return $next($request); 
    } 
} 

В Kernel.php:

protected $routeMiddleware = [ 
     'auth' => \RMS\Http\Middleware\Authenticate::class, 
     'auth.basic' => \Illuminate\Auth\Middleware\AuthenticateWithBasicAuth::class, 
     'guest' => \RMS\Http\Middleware\RedirectIfAuthenticated::class, 
     'isadmin' => \RMS\Http\Middleware\IsAdminMiddleware::class, 
    ]; 

и применяется к маршрутам:

Route::group(['middleware' => ['auth', 'isadmin']], function() 
{ 
    Route::resource('user', 'UserController'); 
}); 

Игнорируется Middleware? Я был уверен, что не добавляю заявление use WithoutMiddleware;.

Answer 1

У вас есть два варианта:

• лучше создавать тесты для пользователя завода, как это может сделать пользовательские типы вы хотите
• разрыв с отладчик после генерации пользователя для его проверки вручную

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

Answer 2

Я бы предложил использовать Аутентификацию пользовательского экземпляра Auth::login($user); для получения более подробной информации: here.

Этот метод применим для Laravel 5.x и выше

Answer 3

В качестве альтернативы: unit tests не должны быть user experience. Для этого будет acceptance или functional тестирование. Один из наиболее популярных инструментов для этого - codeception.Он в сочетании с phantomjs или selenium может эмулировать сеанс браузера и получать полный рендеринг для пользователей.

Per документы доступные на http://codeception.com/docs/01-Introduction документы:

Приемочные испытания: «Приемочные испытания могут охватывать стандартные, но сложные сценарии с точки зрения пользователя. С приемочными испытаниями вы можете быть уверены, что пользователи, следуя всем определенным сценариям, не получат ошибок ».

Функциональные тесты: «Функциональные тесты вы эмулируете веб-запрос (переменные $ _GET и $ _POST) и отправляете его в свое приложение, которое возвращает HTML-ответ. '

Испытания модуля: «Тестирование фрагментов кода перед их соединением также очень важно. Таким образом, вы можете быть уверены, что какая-то глубоко скрытая функция все еще работает, даже если она не была покрыта функциональными или приемочными испытаниями. Это также доказывает, что вы создали стабильный и проверяемый код ».