Writing tests the right way

Photo by Kevin Ku on Unsplash

I haven’t always been the biggest fan of writing tests but I have come to fall in love with it and hopefully, by the end of this article you will understand why.

I always thought that writing tests was time-wasting and that I could manually test if all the actions are working. For example, if the system should allow a user to login then update their status I would manually test it. But what happens when the codebase starts growing? Do you keep manually testing every part of it? What about when you forget one action? What are the repercussions?

As a junior software engineer, in a company with a codebase that has been worked on for about 10 years, it can get a bit overwhelming when I do a story that requires me to alter something in the existing codebase. It gets scarier when a fault in the code could not only lead to downtime or bad user experience, but also actual monetary loss.

Thankfully, Kopo Kopo, Inc. has a broad and robust test suite which makes me more confident in the changes I make. Granted that the test suite is green, you have a good chance that the changes you are making won’t have other hidden repercussions. Saving you insomnia after a deploy.

  • Makes it easier to onboard new engineers into an existing project.
  • Confidence during deploys. You can finally have your weekend free from the ghost of the Friday deploy.
  • Makes code reviews much faster and specific.
  • It increases the productivity of engineers as they are not constantly worried about unseen repercussions of their changes as the robust tests would catch them *most of them anyway.

Writing tests is important, but it is only useful if they are robust. According to the Cambridge dictionary robust means:

strong and unlikely to break or fail

In terms of a test suite, it would imply that the tests have good coverage and they should always make sure that the intention of the logic is met therefore uncovering most bugs.

  • Make sure the basic functionality is well tested including the edge cases and exceptions.
  • Always test for both success and failure. Test for all the scenarios that would result in a successful result and all the scenarios that would lead to failure.

For example:

When testing for validation in a model ensure that you test that it succeeds with all parameters present and it still passes without the optional parameters.

  • When testing for failure, validate the specific errors that you are expecting as opposed to general failing(it may be failing for multiple other reasons than the one you are testing for)
  • Make sure that your tests are efficient. Do not create an actual record in the DB if you are just testing for validation. This greatly reduces the amount of time it takes to run the whole test suite.
  • Maintaining the tests. Tests, like any other component of software, should be regularly maintained. If/when a bug pops up in production you should add the scenario to the tests. This makes sure that the next time you won’t have the same bug in prod as you will catch it when running the tests before deploying.
  • Last but not least, Automate your tests. Make sure they are run after every commit. You could use a CI/CD tool like CircleCI or you could define a pre-commit hook where it runs all the tests before it pushes it to your remote repository.
  • Do not make live API calls when testing. Instead, mock the expected responses to ensure that you are testing the functionality of your application and not of the 3rd party’s service.

Make sure that your tests are readable. It makes maintenance much easier.

“More than the act of testing, the act of designing tests is one of the best bug preventers known. The thinking that must be done to create a useful test can discover and eliminate bugs before they are coded — indeed, test-design thinking can discover and eliminate bugs at every stage in the creation of software, from conception to specification, to design, coding and the rest.” — Boris Beizer

What other tips do you have when it comes to testing? Please share in the comment section below.

Don’t forget to clap if you found this useful.

Photo by Nelly Antoniadou on Unsplash

Software Engineer. Baker. Life enthusiast. Seeing Fuchsia makes me Flutter 😅😉.