When I read the documentation, it is my understanding that when I want to run an integration test, Magento should create a fresh new installation. So I copied install-config-mysql.php.dist to install-config-mysql.php with the proper credentials, the database exists, but as soon as I try to run the most simple integration test:

vendor/bin/phpunit \
    -c dev/tests/integration/phpunit.xml.dist \

... I get the following error (along with a huge stack trace):

Exception: Starting Magento installation:
File permissions check...
[Progress: 1 / 541]
Required extensions check...
[Progress: 2 / 541]
Enabling Maintenance Mode...
[Progress: 3 / 541]
Installing deployment configuration...
[Progress: 4 / 541]
Installing database schema:

SQLSTATE[42S02]: Base table or view not found: 1146 Table 
'magento_integration_tests.store_website' doesn't exist, query was: 
SELECT `main_table`.* FROM `store_website` AS `main_table` ORDER BY 
main_table.sort_order ASC, main_table.name ASC

Now, I could paste the stack trace but there is nothing useful there. That is: there is no reference to my own module whatsoever, nor to any 3rd party modules.

So does anyone have a clue why this happens? My best guess is that somewhere in the code the store table is already referenced prior before it is created (or Magento is installed at all for that matter).

1 Answer 1


And as usual, after hours of trial and error and finally posting my question on Stack Exchange I find the answer myself in the next 10 minutes...

Turns out it was my own custom module. It all bubbles down to dependency injection:

  • My custom module has a console commando.
  • This console commando has a dependency to a custom service contract.
  • This service contract has a dependency that at some point has a dependency to the store manager.
  • When installing a fresh Magento installation from the command line, this custom module was triggered prior before the store module, and because the dependency is in the constructor of a console command, any console command would trigger this dependency chain.

The solution? Adding a proxy solved the trick in my case. So I just had to change my constructor from:

public function __construct(
    MyCustomManagementInterface $myCustomManagement,
    $name = 'foo_bar'
) {


public function __construct(
    MyCustomManagementInterface\Proxy $myCustomManagement,
    $name = 'foo_bar'
) {

Hope this answer helps someone else (or me) in the future.

  • Good to hear you've found the solution to your problem, and thanks for sharing the knowledge with us!
    – Niels
    Commented Sep 21, 2017 at 6:46
  • Could you please elaborate on you how actually define the mentioned Proxy on the related interface ?
    – Syffys
    Commented Jun 14, 2020 at 13:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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