The population service of WorldExplorer might be coded defensively, but we should have proof that it will fail gracefully when issues arise.

Here are some examples of things that could go wrong:

• The network could be down when we make a request or before we receive a result.
• The server might be unavailable.
• The server might return unexpected data (for example, missing data, incorrect types, HTTP errors, and many others​).
• The code making use of the service could provide invalid input (for example, for the dateRange property, for the country property, and many others).
• We might have forgotten to handle some error types.
• We might have forgotten to perform some validations.
• Maybe our code will break if too many results are returned at once.
• Maybe our code has security flaws that might get exploited.
• Maybe our code will break if we switch to a newer version of TypeScript or some library.

These only scratch the surface of the myriad of potential errors that could affect our code and thus the users of our application. The only way for us to increase our confidence in the code is to test it.

The objective of testing is to detect as many potential issues as early as possible in the development cycle to reduce their likelihood, their severity, their impact, and so on. The sooner issues can be discovered, the less it should cost to fix them.