Limitation in code buckets and tests

oezkan.yilmaz

Hello,

We are currently using a multi-DB setup for our stores (DE, EN, CH), where each store has its own database. When running tests via docker/sdk cli -t or docker/sdk testing, the default store is used. In our case, it is DE (as defined in the deploy.ymlfile under docker:testing:store:).

We have reached a point where we need to run tests in the context of EN or CH to verify if the code buckets for EN/CH logic are functioning correctly. Unfortunately, we haven’t found a way to enter the test mode while providing the store context, as the value of DE is hardcoded into a .env file when bootstrapping the project.

When entering the CLI via APPLICATION_STORE=EN docker/sdk cli, we can see in the terminal's output that the store is set to EN, which means, we can set the current context for the cli. However, when running APPLICATION_STORE=EN docker/sdk cli -t or APPLICATION_STORE=EN docker/sdk testing the store context reverts to DE (the default store) and APPLICATION_STORE is ignored. Which looks like, there is no way to set the default store from outside to run the tests.

We got following suggestions by the sprykers support team in the partners portal so far:

Option one

If you specify APPLICATION_STORE=EN before test execution command, it should probably work.

docker/sdk testing APPLICATION_STORE=AT console queue:worker:start --stop-when-empty

This is not working, since we are getting propel exceptions, because the database configs are not aligned. In this approach we are still in the DE store context and only providing the APPLICATION_STORE before the test command, which has no effect for the cli.

Option two

We also suggest having several deploy.yml  with different settings for testing different stores:

First

docker:    

  testing:        

    store: DE

Second

docker:    

  testing:        

    store: EN

Third

docker:    

  testing:        

    store: CH

This is not working, because we are expecting more than 20 different stores, which would lead to have more than 20 deploy.ymls to run tests. This would also mean, that we would need to bootstrap each time, we are changing something in another store context, to run tests.

Option three

I would also like to inform you about our platform CommerceQuest (), it is a community where you can post problems or questions and that would be answered by community experts. 

Since we got no better idea, we would like to ask, if you had similar challenges, when running tests in the context of a different code bucket.

I am happy to get any support and other ideas about that topic.

Thank you