AbstractBackendControllerを使用した構成ページのテスト：testAclNoAccessが失敗する

構成セクションの統合テストを作成しているときに、デフォルトのテストケースで次のエラーが発生しました。

My\Module\ConfigTest::testAclNoAccess
Failed asserting that 302 is identical to 403

私の知る限り、すべてが正常に機能しますが、Magentoは、構成セクションでアクセスが拒否されたときに、「禁止」ではなくリダイレ​​クト応答を送信します。

テストを変更して302ステータスコードを期待するのは理にかなっていますか？このテストケースは、間違ったリソース識別子をキャッチするのに既に役立っているので、削除しないほうがよいでしょう。

これは関連するコードです：

namespace My\Module;

use Magento\TestFramework\TestCase\AbstractBackendController;

class ConfigTest extends AbstractBackendController
{

    protected function setUp()
    {
        parent::setUp();
        $this->uri = 'backend/admin/system_config/edit';
        $this->resource = 'My_Module::config_my_module';
        $this->getRequest()->setParam('section', 'my_module');
    }

    // [other tests]
}

テストを変更して302ステータスコードを期待するのは理にかなっていますか？

はい。以下は、testAclNoAccess（）のデフォルトの実装をオーバーライドし、十分な権限がないシステム構成領域にアクセスするとリダイレクトが発生することを確認します。

public function testAclNoAccess()
{
    $this->_objectManager->get('Magento\Framework\Acl\Builder')
        ->getAcl()
        ->deny(null, $this->resource);
    $this->dispatch($this->uri);

    //denied access in the system config redirects
    $this->assertTrue($this->getResponse()->isRedirect());
}

問題との関連性は低いようですが、フォローアップを投稿していますが、私や他の人を助けることができるかもしれません。バックエンドコントローラーテストで同じエラーが発生します。Failed asserting that 302 is identical to 403

ただし、私の場合、このエラーは、コアモジュールまたは独自のモジュールのすべての（！）統合テストでスローされます。私は次のテストが失敗するように物事を絞り込みました：

$this->assertTrue($this->_session->isLoggedIn());
$this->dispatch($this->uri);
$this->assertTrue($this->_session->isLoggedIn(), 'Session is no longer valid');

そのため、何らかの理由で、ディスパッチされるとセッションが中断します。私は別の環境でこれを再現しようとしましたが、失敗しました。テストは他の場所で機能し、これはテストコードが間違っているためではなく、環境内の何かが原因で失敗することを証明しています。私はすでにすべての論理的なステップ（書き込み可能なセッションディレクトリ、代わりにRedisを使用、他のセッションとCookieの設定、PHPの切り替え）を経験しましたが、まだこれを解決していません。

他の人が同じエラーを経験している可能性があるため、これを投稿したかったのですが、テスト自体ではなく環境自体に関連しています。