Introduction to Testing @ Boxhub
Something I’ve found since starting here at Boxhub is that things advance very quickly at times, a plethora of new features and functionalities are added every day, fires are put out, and new potential pitfalls are introduced by bug-fixes meant supposed to douse said fires.
This fast pace of development has helped me truly realize the need to fully test our features and applications, catching potential side-effects of a “small feature” before they are pushed to production where they can cause issues in the day-to-day business functions of the company.
This lead to our quest for a testing framework which would help us in this never-ending endeavour to rapidly engineer features that provide value to the startup. All the while ensuring we don’t accidentally break key components of the application when pushing to production.
What we went with
For this task, we evaluated a variety of testing frameworks for our Dispatch Tool which is built purely using Next.JS in both the front and backend. After making various proof of concepts with different frameworks we decided to use Cypress, some of the reasons include:
- Has a great GUI interface: Tested browser on the right side, with a history of commands that were run on the left side. This allows for rapid testing, and the ability to go to various parts of the test to see what occurred in the process.
- Tests are automatically ran when specs(tests) are saved, saving devs time allowing for quick feedback on the changes made.
- Can easily intercept API calls. (Hydrate with custom data or mock authentication)
- Multi-browser support
Takeaways
The implementation of testing in our application has helped find various issues and bugs in the application that wouldn’t have been noticed prior to a testing framework being introduced.
A key example was the introduction of a new feature which allowed for multi-email support for various tables in the application. While the feature worked when tested manually, the unknown side-effects of this feature caused things to break in other parts of the application which weren’t utilized frequently, but are important parts of the Dispatch app. Bugs like these wouldn’t of been found for quite a bit of time, and may have existed for even longer if tests weren’t created to go through the flow that a user goes through while using the application.
Next Time…
How we implement testing at Boxhub