Intro
So, why is writing tests for software so hard? For me, it always used to be hard because I did not know how I should write my tests and what exactly to test. Recently, I came to the conclusion that writing tests is actually quite simple. It’s all about understanding what to test and getting a little bit of practice. The TLDR of this article is: Just test the interactions your users make with your software. Read on to learn more.
Why Bother with Tests in the First Place?
This is a valid question. Why should we write more code in order to make sure that some other code actually works? Doesn’t this increase the total amount of code we need to maintain? Now we have our application code PLUS a large amount of test code to maintain. This can seem counterintuitive.
But, if we learn what to test, we will soon find that the test code is quite brief and to the point.
What are Tests Good For?
Writing a test makes me think about the use cases that the code I write has to handle, and under which circumstances it should or should not function. So, it’s actually a specification of what our code needs to do. Ideally, a programmer would never have to consider this, but from my experience, this is rarely the case in the real world. In fact, most stakeholders simply don’t have the technical understanding to consider all the edge cases that can happen in a piece of software code. So this becomes our job as a programmer and to communicate this to the stakeholders.
After having defined the use cases for our code, we can translate it into a piece of code quite easily. This has the huge advantage of making us consider our use cases before we start writing any code. An even greater advantage of writing it into the codebase, where our code resides, is that other programmers joining the team later on will still have a reference to the use-cases our code was designed for. This will instill greater confidence in a new team member pushing code into production. The advantage of writing the specification alongside the code it specifies is the best place to have this specification, as this is the only place any new developer will (and should) look for reasons why a piece of software functions as it does.
How Do I Learn to Write Tests?
Like with every new skill one learns, it is hard at first until you get the grasp of it and experience some of the problems you need to solve. This journey may have a steep learning curve with its fair share of ups and downs. But, by the end of it, I assure you, you’ll emerge as a better programmer. If you wish to receive personalized advice to address your concerns specifically, don’t hesitate to schedule a one-on-one session with me. You can reach out to me via the Contact Form.
The most important question, in my opinion, is: What should I test? There are many different resources on this, but the essential question is: What do my users expect from my application or piece of software? Users can be anyone using your software; even other software consuming your software (APIs) can be considered as users. Because, ultimately, we write the code for them. We should write our tests in the same way our users will end up using the code.
What Should I Test?
An Example: Let’s take a Shopping List App as an example. What are the most important use cases a user of this app would have? From my perspective, I’d want to track a list of items that makes up my shopping list. Ideally, my partner would also be able to add or complete items on the same list. Given that as our core software, this is what we must test:
- We have a minimum of 2 users who can add and complete items on a checklist. It should also be possible to complete items which another user with access has added.
Our tests can be formulated like this:
- After User A adds items to a checklist,
- User B should be able to see the added items on their checklist.
- After User B completes one or more items on the checklist,
- User A should no longer see the completed items on their checklist.
This simple test validates the core functionality our software was designed for.
There will be a few edge cases one could but doesn’t necessarily have to test. One example is offline usage; what happens when User A is offline and adds apples to the shopping list. Maybe at the same time User B also adds apples to the list, while User A is still offline. I’d argue that this is an edge case that isn’t crucial for the app to fulfill its core function.
This needs to be evaluated and considered for each different use and edge case. The rule I derive from this is: How likely is it that your users won’t continue using your app if this functionality does not work? If the likelihood is high, then it’s probably a good candidate for a test.
If this functionality is something that only a small percentage of users will ever use, you’re probably better off not including it in a test. This is the simple Pareto principle: Test the core functionality that makes up 80% of your software’s features, which should only take around 20% of the time to create and maintain these tests.
Does this sound complicated? You don’t want to invest the time to learn how to write proper, value-driven tests? Ask me to join your team, or you can book a 1-on-1 session with me to help you level up.
Conclusion
In conclusion, the creation and maintenance of effective software tests are significant factors in ensuring the delivery of high-quality software. Writing tests can initially seem daunting and counterintuitive due to the increased code maintenance. However, by homing in on what the users expect from the software, we can tailor the tests to ensure that they truly serve the software’s core functionality. As we become more accustomed to this testing mindset, it becomes less of a chore and more of an integral, and natural, part of the software development process.
Not all functionality needs to be tested - we should focus primarily on the core features that most users will use. This method leads us to adhere to the Pareto Principle, writing tests for the prominent features taking only a fraction of our total time.
Finally, remember that uncertainty should never be a barrier. Don’t hesitate to seek professional guidance if still in doubt about creating effective tests. One on one training or additional team support could be the missing piece of the puzzle in mastering the skill of writing value-driven tests.
Contact
I truly value your feedback and would love to hear from you regarding any questions or comments you may have. Please, do not hesitate to reach out to me at website[@]meerkat-software-solutions.com. I look forward to supporting you on your software testing journey.
