Testing: What, why, how and when?
What is testing?
- Testing is a practice where we write code to check if (ideally) every single function/component/API/page is working as expected in different scenarios (user being/not being logged in etc).
- Tests help us from manually testing every single thing by ourselves once we make some change somewhere in the codebase.
- Tests also let us know if our current changes are breaking any existing features of the project, so we can code and push confidently as developers.
Why testing?
- Imagine for a certain task you needed all the details of a user. So you write an API which fetches the details of a particular user, performs something on it and returns all of the details. Those details may contain private information like email address, phone number etc. Any user could see any other user’s private information. That would be a HUGE privacy concern, right? Even if the result is unintended, the damage is real.
- What could you do to save it? One option is to manually go and check every single API after your changes are done, to check if they’re working fine. It can become boring and tiresome as soon as the number of APIs go up. Also, humans are prone to errors. One may easily miss an important field being returned which was not supposed to be returned.
- That’s why tests can be your saviors. They’ll do the testing part for you. They’ll save your time, energy, effort and of course, save your job 😛
Though I have mentioned only about APIs and stuff, tests do exist for frontend as well. Now that we understand what is testing and why is testing necessary, let’s see what kind of tests we should write. I’m pretty sure you’d have seen those articles/videos where the only tests are to check if 2 + 2 is 4 😂. We won’t be doing that here though. We’ll be looking at logic of some real-life tests. We won’t be writing tests in this blog though.
Case 1:
Let’s take the above scenario itself. You would have an API for the user details, right? That API will get you the required data from the database. You have to make sure that the API is returning all the details which are necessary: first name, last name, their projects, pull requests, commits so on and so forth. At the same time, you have to make sure that the API is NOT returning any sensitive data at any time, like phone number and email address.
Now that you know the expected behavior of the API, we should move to writing tests. So what should the API tests look like?
Case 2:
Let’s assume you’re working in LinkedIn. You see an edit profile button when you go to your profile, right? What happens when you go to someone else’s profile page? You shouldn’t see the button. Let’s see what could be the logic for some of the tests:
I hope now you’re getting what we mean by tests, but hey! When/where do these tests run? Good question! 😆 Once you work on a feature, you commit your changes, you create a pull request, let’s say on GitHub. On GitHub, in the repository you’re making the pull request, they’d have set up Continuous Integration pipeline. This pipeline/setup will run all the tests in that project on your pull request, that is, on your changes. So you’ll get to know what things you’re breaking (if any) with your current implementation, before it is actually merged into the repository! 🎉
This is one example of the one set of the tests being passed on one of the pull requests Real Dev Squad’s website-backend project:
In this way well written tests are there to save us from breaking expected functionality/design of our projects 😉
This was just a high level overview of tests, what they are, why are they required, what kind of tests do we write, where do they actually test our code. In the next blog, we’ll actually write some tests — coding time! Again, we won’t be writing tests to check if 2 + 2 equals 4 😛 We’d actually write some meaningful tests which you can incorporate in your projects/job 😊
I hope this article helped you in some way. Nonetheless, have a great day! 🎉
