Laravel 5 / Codeception 路由不正确

Laravel 5 / Codeception not routing correctly

我正在尝试使用代码感知为控制器函数编写一个 API 测试用例,我遇到了一个问题,即到控制器函数的路由似乎没有被正确评估,并且评估似乎有所不同,具体取决于我在测试用例中的内容。

这是我的测试用例中的代码示例:

use \ApiTester;

class CustomerRegisterCest
{
    // tests
    public function testGetRegister(ApiTester $I)
    {
        $I->sendGET('register');
        $I->seeResponseCodeIs(200);
    }

    public function testPostRegister(ApiTester $I)
    {
        $I->sendPOST('register', [
            // set the data in here
        ]);
        $I->seeResponseCodeIs(200);
    }

我有一个包含这些路由的 routes.php 文件:

Route::get('/', ['as' => 'home', 'uses' => 'HomeController@getIndex']);
Route::get('register', ['as' => 'getRegister', 'uses' =>'RegistrationController@getRegister']);
Route::post('register', ['as' => 'postRegister', 'uses' => 'RegistrationController@postRegister']);

我已经在我的控制器 类 中插入了一些调试语句,这样我就可以看到得到了哪些路由 运行,像这样:

    Log::debug('GET register');  // or GET index or POST register, etc

目前我已经从我的控制器类中删除了所有内容,因此只包含调试语句。

当我运行上面的测试用例时,我得到以下调试输出:

GET register
GET index

... 所以看起来 sendPOST('register', ...) 实际上路由到“/”的 GET 路由,而不是“的 POST 路由/登记”。在测试用例之外一切正常——我可以 POST 注册路由正常,路由似乎工作正常,问题只出现在代码接收测试用例中。

如果我更改测试用例,以便在同一个函数调用中执行 sendGET 和 sendPOST,例如:

    // tests
    public function testPostRegister(ApiTester $I)
    {
        $I->sendGET('register');
        $I->seeResponseCodeIs(200);
        $I->sendPOST('register', [
            // set the data in here
        ]);
        $I->seeResponseCodeIs(200);
    }

然后我看到这个调试输出:

GET register
GET register

... 这样通过将 sendGET 插入到与 sendPOST 相同的函数中,它改变了 sendPOST 的行为,因此它现在路由到 GET 路由以进行注册索引的 GET 路由(但仍然不会路由到正确的 POST 路由)。

我已经尝试打开 xdebug,但从 xdebug 输出中也没有任何关于发生了什么的线索。

经过大量的命令行调试(使用 phpstorm),我想我找到了答案:

控制器中的POST注册路由处理函数声明如下:

public function postRegister(RegistrationRequest $request)
{

...需要通过依赖注入传入一个 Request 实例。该请求包含一些验证代码,如果由于某种原因验证代码无法完成(例如抛出异常),则永远不会调用控制器函数——因为构建请求失败。

这在浏览器领域会抛出 500 错误,但在代码接收领域,异常的捕获方式不同,它 returns 重定向到 / 没有数据。这一切都发生在控制器函数之外而不是控制器函数内部,因此控制器函数中的 Log 语句永远不会运行,因为该函数永远不会被调用。 codeception 中的异常处理程序是一个通用陷阱。

隐含的建议是,控制器中的依赖注入可能不是一个好主意。或者,也许通用异常处理程序不是一个好主意。