So far, we've seen how to test the code properly in the cleanest way possible. However, it's not always possible to find the code in the perfect state – testable and isolated – so this section will cover a few helpful tips.
The singleton is one of the most controversial designing patterns. Its aim is to have one, and only one, instance of a particular class in our code base, but what happens is that we abuse the global nature of the singleton to have all the dependencies at hand when we need them. In this way, however, we are losing the power of DI as we have seen in Chapter 11, Implementing Dependency Injection. Since a Singleton cannot be instantiated, it cannot be replaced with a test double. In his blog (https://www.swiftbysundell.com/), John Sundel demonstrates a few steps to make a singleton replaceable at testing time.
Let's try some code that relies on URLSession.instance to work:
class DataFetcher {
enum Result {
case data(Data)
...