I'm writing an integration test for a configuration section and encountered the following failure from the default test cases:

Failed asserting that 302 is identical to 403

As far as I see, everything works as it should, but Magento sends a redirect response instead of "Forbidden" when access is denied on a config section.

Does it make sense to change the test to expect a 302 status code? I would rather not remove that test case as it already helped me catching a wrong resource identifier.

This is the relevant code:

namespace My\Module;

use Magento\TestFramework\TestCase\AbstractBackendController;

class ConfigTest extends AbstractBackendController

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

    // [other tests]

Does it make sense to change the test to expect a 302 status code?

Yes. The below overrides the default implementation for testAclNoAccess() and checks that a redirect happens when accessing the System Config area with insufficient permissions.

public function testAclNoAccess()
        ->deny(null, $this->resource);

    //denied access in the system config redirects

I'm posting a followup, even though it seems it is less related to the issue, but it might help out me and others. I get the same error in a backend controller test: Failed asserting that 302 is identical to 403

However, in my case, this error is thrown on all (!) integration tests of either core or my own modules. I have narrowed things down to the following test failing:

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

So, for some reason, once dispatched, the session breaks. I've tried to reproduce this on another environment, but failed: The tests work elsewhere, proving that this breaks not because of wrong testing code, but something in the environment instead. I've gone already through all of the logical steps (session dir writable, using Redis instead, other session and cookie settings, switching PHP) but have not solved this yet.

I wanted to post this, because it might be that others are experiencing the same error, while it is not related to the test itself, but the environment itself.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.