Test Structure

Now that we have the basic test written, let's iterate on it. See, no matter what we test, we will be repeating the same steps over and over:

Execute the code;
Compare the actual result with the expected result;
Throw an error if those two don't match.

In other words, every test follows 📜 a predicatable structure. And that's great! It means we can open any project and go to any test and follow that structure to help us navigate around and understand things. It also helps with writing tests because it gives us this framework on how to approach testing anything.

Test phases

The "Execute-Compare-Throw" loop is what our tests are doing conceptually but on the structural level, every test consists of the following phases:

Setup (optional). Addressing any dependencies our code needs to run (e.g. side effects like a database connection or an HTTP request to the server).
Actions. Using the tested code (e.g. calling the sum function with particular arguments).
Assertions. Validating the intention (i.e. comparing the actual and the expected states of the code).

In this exercise, you are going to refactor the existing automated test to reflect that structure.