Lastly, let's look at the API service. Normally, the service in a front-end application behaves much like the repository in a back-end application. The service's main function is to abstract data interactions with some data source. Those interactions don't necessarily contain any definable business logic. The real logic, if any, for a service exists on the server and doesn't need to be tested as part of a front-end application. At least it doesn't need to be tested the way you might think it does.

So, if the service doesn't contain any business logic, and Redux doesn't contain much business logic, and the components don't contain much business logic, what do we test and how can it be unit-tested?

The short answer is that we are not off the hook for testing, but we will have to jump through some hoops to do any testing because it is difficult to remove ourselves from integration testing. In a typical front-end application, unlike in C#, there is no clear division between our code and their code. So, we will have to make some concessions and write quite a bit of code to abstract parts of third-party code to allow us to test what we need to be testing.

So, where does this leave us when it comes to a testing direction?  Unfortunately, there doesn't seem to be a clear winner. For the purposes of this application, we will work from the data source up so that we have a clear understanding of the data manipulations available to us while we write user interface aspects of the application.