Dev Hobby - Test and verify everything, every time

Sometimes confidence comes from having experienced a thing many times. In the world of coding, there are times when you just needed to add a few lines of code to modify a feature or functionality. Sometimes you are using a robust framework, and you have written this logic many times over, and so it feels second nature. It is at this point bugs get introduced.

Sometimes confidence comes from having experienced a thing many times.

When working on projects and especially when you trying to speed through releases or launch quickly using the MVP mantra, there is a tendency to ignore tests. Tests aren’t the most fun things to write, but they provide immense value to the lifetime and evolution of a project.

I am currently building a mobile shopping app that needs to consume an API. I have my deployment process automated using Github Actions and Docker. I follow the Gitflow branching pattern and have my environment variables setup on Github secrets. Pushing a release branch to the remote repository automatically deploys the latest to the server. The design makes it quick and easy to iterate through tasks and ideas and make corrections quickly.

I am also using the API Platform framework built on top of Symfony framework, which makes building CRUD API endpoints a breeze. Coupled with a bit of Doctrine ORM dust, the coding experience feels almost declarative if you read the docs and know the plumbing well enough. Now, why did this come about?

I wrote an endpoint for fetching ShoppingLists; it allows you to make a simple GET/POST/PATCH/DELETE type of operation. The first time I wrote this, it all worked, and I did manually test it. However, when building the mobile app, I needed to display the date of the shopping lists. In my initial model design, I didn’t include the createdAt or updatedAt field and so adding a new database column and migration isn’t a big deal. I did that and pushed to the staging server.

Everything deployed, and I didn’t bother to test. So I am not at a point I need to update the mobile app code to create a Shopping list entry and 500 server error spews across the screen. I tracked down the reason for this, and this was as a result of me missing to add a trait that automatically sets my date time on database record insert or update. A slew of Functionality tests would have caught that.

I had initially started writing tests scripts using the Postman tests. I didn’t do much, but from this experience, to avoid such delays in the future, updating the tests to all the endpoints I will be adding will ensure future updates don’t break existing functionalities. This aspect will reduce time wastage and feature development momentum.

The lesson from this experience is no matter how confident you feel your code is, always write tests. You will never think of everything every time, but tests hold a history of what you have done before and how that will match up with what you intend to do next.