Notice: You are browsing the documentation for PrestaShop 8, which is currently in development.You might want to read the documentation for the current version, PrestaShop 1.7.
PrestaShop is a complex software and uses automated testing to ensure that the new additions to the codebase do not break existing behaviors.
Automated tests are located in
tests folder, you will find:
Unit tests are powered by PHPUnit. They test one and only one php class, mocking/stubbing any dependencies that class has.
Unit folder meets some rules:
If there is a hard-coded dependency such as a singleton pattern being used or a static call, this class cannot be unit tested and should be tested using integration tests.
testGetPrice(no idea what such a test is supposed to do)
Unit tests can validate the behavior of a php class when it can be isolated. However, some classes cannot be validated this way. Moreover, a lot of logic from PrestaShop is written into complex SQL queries that cannot be validated by those kind of tests. This is why we also need integration tests.
We use 2 technologies for the integration tests in the
Finally, we have some user interface tests (also sometimes referred to as web acceptance tests). These tests launch and control a browser that will then go on either the Front Office or the Back Office of a shop and perform several actions to check that the behavior, from the point of view of a browser, is as expected. So these tests send real HTTP requests and check the returned DOM.
These tests can be found in
UI tests rely on Playwright.
We are currently refactoring how the test folder is structured. As this is a huge work that is going to take months, we have chosen the following strategy:
Tests that we are not satisfied by remain in the
tests-legacy folder and will be, one by one, replaced by tests of a higher quality inside the
We keep the legacy tests as they have value (they can detect mistakes in the modifications we bring to the codebase) but they are not being updated anymore as we want to replace them.
Theses tests were powered by PHPUnit but were not unit tests: they were integration tests, which means they would test several classes together and would run additional services such as a database. This has made this test quite complex and sometimes lead to random failures.