Running an integration test doesn't create a new Magento Installation

Question

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 \
    app/code/Vendor/Module/Test/Integration

... 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:

[Zend_Db_Statement_Exception]
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).

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'
) {

to:

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

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