Contributing to Ecotone
- 1.To run your local environment with tests:
.envand start docker containersdocker-compose up -d
- 3.To run tests for
monorepo:docker exec -it ecotone_development composer tests:local
- 4.To run tests for given
moduledocker exec -it -w=/data/app/packages/Dbal ecotone_development composer tests:ci
- 5.Clear development environmentdocker-compose down
- To have enabled debugging all the time, change line in your
.envfile toXDEBUG_ENABLED="1"and rebuild containers:docker-compose down && docker-compose up -d
- As having xdebug enabled all the time, may slow your test execution, you may run it conditionally for given test casedocker exec -it ecotone_development xdebug vendor/bin/phpunit --filter test_calling_command_on_aggregate_and_receiving_aggregate_instance
If you're asked about mapping path, map your xdebug server to "
/data/app"and name it "
project", if you have not changed xdebug project name.
- Make use of real providers in tests - This means, if integrating with RabbitMQ/SQS write tests that actually make use of this Message Brokers. This will ensure, that tests will stay the same, even if underlying 3rd party library/SDK will change.
- Focus on client level code - Your tests do not need to test every single class you add to the repository. It's more valuable from perspective of long term maintenance to focus on tests that will be testing on the high level (using Ecotone Lite). Those tests will be also similar to the ones, you will be writing in your own Ecotone based projects.