WooCommerce Store Testing or How We Caught Bugs

An American manufacturer and seller of b2c nail polishes migrated the website from Magento to WooCommerce. After that, technical changes were needed, and our team was part of a large distributed team to implement them. Testing was an important part of the work. Let’s see how we implemented it.

The site was being actively developed at that time, which required frequent releases. And, therefore, regular checks of the site for errors in the main and additional functionality were necessary. Testing and teamwork were organized at a high level:

• all tasks in the Jira task manager;
• each task had a separate feature branch for easy testing;
• the code listing was fine-tuned before being sent to the repository (phpcs);
• the product team (on the client side) was deeply involved in the testing process.

Finding bugs was complicated by a large number of releases and the presence of some legacy code from an old Magento project. Because of this, errors appeared in places where we did not expect them. Since this is an active online store, some mistakes could be costly. For example, if a customer could not place an order, the company would lose profits. For this reason, it was decided to implement a system of automatic e2e (end-to-end) tests that ran the store’s main and most important pages and functions.

The process of writing automated tests is very painstaking and takes a lot of time. It took a month to create them for this project. With these tests, we were able to recreate an environment that simulated user actions on the page.

The process is configured using the codeception testing framework. Let’s take a closer look at how automated tests work:

• The test launch step is included in the deployment pipeline.
• At this moment starts a virtual machine that uses the Selenium engine (headless browser).
• Tests from PHP code are interpreted into real actions of the “user” – hover over the button, click, find the field, enter data, see if the element has appeared, etc.
• Codeception performs all these actions and at checkpoints compares the expected result with the real one (for example, did the data validation check error occur in the form or did we see a success message after a few seconds).
• If any of the actions lead to the result that we expect, the execution of the script (test case) will end with an error.
• When debugging, the programmer just sees it in the console and continues to edit the test.
• And when deploying the pipeline will simply stop and send a notification to the team chat that it tried to upload something wrong

The first week was spent working on repetitive activities and designing the architecture. Our task was to design the optimal path for passing tests to the maximum so that they take not an hour, but a few minutes (before that, the client had an unsuccessful attempt to implement this technology and we started with a version that runs the most basic add-to-cart scenario for about 10 minutes and purchases – it was impossible to scale without optimization)

Once we had a stable and fast first case, we scaled this approach to all the large website’s main features, for example:

Automated tests covered the verification of functions such as registration, authorization, profile editing, shipping data editing, favorite payment methods editing (linked cards, etc.), and wishlist management.

Adding, changing the quantity of a specific item, recalculating free shipping, changing the delivery address in the basket, recalculating the totals of the basket depending on the entered data, and calculating delivery for an authorized client.

In these tests, we also covered complex custom functionality in the admin panel, since content creators regularly had problems with this and the client wanted to always be sure that everything worked smoothly. Adding, checking banners/sliders on the frontend (after adding), checking on the main and other options.

This is one of the most important online store functions. We covered checking shipping method selection, logging in from the order page (with cart consolidation and updating saved shipping and payment methods), checking coupons and reward points (reward points are a separate reward system used by the customer), buying multiple items in 1 cart, changing country, and purchasing with a gift card.

Checking various filtrations, sortings, functions on the product page, permalinks of products and categories, and outputting the expected blocks on all pages of the product category and archives. More than 1700 lines of different checks and database queries for comparison.

In addition, our WordPress website developers wrote tests that checked the work of the Rewards Club. Quite a responsible function, because users don’t like it if they don’t get at least 1 point.

It was an interesting and difficult month of painstaking and responsible work, requiring a deep understanding of the project and all its features (functions in the admin panel and on the front). The cost of the error was even higher than if these tests did not exist at all. After all, if the test worked incorrectly, and the bug is still in production, it’s even worse. However, we managed, and implemented this system in the development process for years, and also significantly improved the quality of all subsequent releases. 

Interesting fact! While we were developing tests, we found a dozen bugs from old releases. Thanks to an integrated approach, they had no more chances to appear. Have bugs or performance issues on your website? Write to a professional WordPress development agency now!