Testen Sie die Konfigurationsseiten mit AbstractBackendController: testAclNoAccess schlägt fehl

10

Ich schreibe einen Integrationstest für einen Konfigurationsabschnitt und habe in den Standardtestfällen den folgenden Fehler festgestellt:

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

Soweit ich sehe, funktioniert alles wie es sollte, aber Magento sendet eine Umleitungsantwort anstelle von "Verboten", wenn der Zugriff auf einen Konfigurationsabschnitt verweigert wird.

Ist es sinnvoll, den Test so zu ändern, dass ein 302-Statuscode erwartet wird? Ich möchte diesen Testfall lieber nicht entfernen, da er mir bereits dabei geholfen hat, eine falsche Ressourcen-ID zu finden.

Dies ist der relevante Code:

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]
}

— Fabian Schmengler
quelle

3

Ist es sinnvoll, den Test so zu ändern, dass ein 302-Statuscode erwartet wird?

Ja. Im Folgenden wird die Standardimplementierung für testAclNoAccess () überschrieben und überprüft, ob beim Zugriff auf den Systemkonfigurationsbereich mit unzureichenden Berechtigungen eine Umleitung erfolgt.

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());
}

— Kristof bei Fooman
quelle

1

Ich poste ein Follow-up, obwohl es anscheinend weniger mit dem Problem zu tun hat, aber es könnte mir und anderen helfen. Ich erhalte den gleichen Fehler bei einem Backend-Controller-Test:Failed asserting that 302 is identical to 403

In meinem Fall wird dieser Fehler jedoch bei allen (!) Integrationstests des Kerns oder meiner eigenen Module ausgelöst. Ich habe die Dinge auf den folgenden fehlgeschlagenen Test eingegrenzt:

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

Aus irgendeinem Grund wird die Sitzung nach dem Versand unterbrochen. Ich habe versucht, dies in einer anderen Umgebung zu reproduzieren, bin jedoch fehlgeschlagen: Die Tests funktionieren an anderer Stelle und beweisen, dass dies nicht aufgrund eines falschen Testcodes, sondern aufgrund eines Problems in der Umgebung funktioniert. Ich habe bereits alle logischen Schritte durchlaufen (Sitzungsverzeichnis beschreibbar, stattdessen Redis verwenden, andere Sitzungs- und Cookie-Einstellungen, PHP wechseln), aber dies noch nicht gelöst.

Ich wollte dies posten, weil es sein kann, dass andere den gleichen Fehler haben, obwohl er nicht mit dem Test selbst zusammenhängt, sondern mit der Umgebung selbst.

— Jisse Reitsma
quelle