What to test?

I'm pretty sure most of us coded multiple of projects without really writing any tests and then saw all those other programmers talking about how incredibly important tests are, how they provide peace of mind, and so much more! Seems like heaven and very appealing, but where to start?

I tried multiple times to get going, and every time, I would set up everything only to be left staring at a blank screen without fully knowing what to test. In my mind, each test I could think of seemed either too simple to deserve to be a test or didn't make sense. In this article, I'll go through some situations, how to think about them and what to test. I hope by the time you finish reading this, you'll have at least a couple of ideas about what to test on your projects, and if you found this useful let me know.

Simple leader board

Let's imagine you work at AllTheSmarts, a company providing machine learning services and integrations. Every day during lunch, you play ping pong with 3 of your colleges. You got to the point where you'd like to register the results of the matches and display them along with a leader board on a webpage for all the company to see. Naturally, the 4 of you, being developers, started to build it quickly. It's nothing too fancy so what should you test?

1. When you request a page, what can you use to validate if it's correct? Well, you can probably use the title of the page or a bit of text. So, write a test to make sure the title and text are present on the page. This test is useful many many times.
2. Since you decided to use a database to store your data, how do you make sure you are loading it properly? One way to do it is to seed your database with ten matches (or any other random number) and test that they are all displayed properly on the page.
3. Since each match has a date, you decided to allow your visitors to sort the list of matches by date. That being the case, test the order of the matches when ordered by date but also by default. Keep in mind that sorting can go in 2 directions: ascending and descending. Test that too.
4. Also, remember to test unexpected inputs. What if...? What if instead of receiving a GET /matches?order=date, you receive a GET /matches?order=dateeee? If your code prevents issues like these, then add some tests around that logic too.

Simple but protected webpage

After six months, you notice the traffic is skyrocketing, which is weird knowing only 4 people are playing ping pong and the company has only 20 people... It turns out, Gay LaVente, one of the developers, has been sharing the link of the leader board with his friends and family to brag about being the best. Since this is an internal and healthy competition, you all decide to add a login page to prevent further situations like this. So, what do you test? On the login screen, ...

1. Test that the user receives the page correctly. You can use some fixed text again.
2. If a user enters the wrong email, test that the response shows a descriptive error. The same goes for the password.
3. If the user enters good credentials, then validate he is correctly redirected to the leaderboard. Perhaps test the title again to validate he ended up on the correct page?

Simple but protected webpage with back-office

So, up until now, you had only four players: Gay LaVente, Anna Gramme, Selina Lemon, and Sonny Day. Since all of them are developers, adding a new match would be done using an SQL INSERT statement. This worked up pretty well, until Jim Bagg, the new designer, wanted to play too. You all tried to teach him SQL but to no avail. You realized you needed a page to add/update your matches. What do you test on that page?

1. Test if the page (form) is displayed correctly - like we did a couple of times already.
2. If a user submits the form without inserting any data, the response should display some errors. Test that. The same goes for the validation: if a user tries to record a match that happened in 2121, he should get a message saying the date is invalid and the match was not saved. Test that too.
3. When the user submits a good match, he'll probably be redirected to the leader board, test that he is. While there test that the new/updated match is displayed with the correct info.

Simple but protected webpage with a back office and an API

Eventually, you hire Aude Vaiselle. She's the best mobile developer there is and tells you she can build pingpongster, a mobile app to display but also create/edit matches. This is perfect, the only thing she needs is an API. So, while creating that API, what should you test?

1. For the different endpoints start by testing they always respond with the expected JSON structure.
2. Then it's pretty much the same as before but with JSON instead of HTML. When something goes wrong (wrong email or date), test you receive the proper message. When something goes right, test you receive the expected JSON, and so on.

Your turn

We've seen different situations and what to test. I hope it was useful and I suggest you try to apply the same way of thinking to your project and start filling that empty test suite. Remember to test the "success" cases, but also the cases when something goes wrong. Test the obvious but also try to think about the edge cases. Lastly, keep in mind that you should test everything but it’s probably not the way you want to start because it may take too much time and diminish your motivation. So try to time-box it and write the most impactful tests possible to give you some peace of mind.