# Avoid Singletons to Write Testable Code

DevFeed: [Avoid Singletons to Write Testable Code](<https://devfeed.tech/articles/avoid-singletons-to-write-testable-code-24945.md>)

Original publisher: [Read original article](<https://codeahoy.com/2016/05/27/avoid-singletons-to-write-testable-code/>)

Author: umer

Published: 2016-05-27T00:00:00Z

Content type: tutorial

Language: en

Sources: [Code Ahoy - Articles](<https://devfeed.tech/sources/code-ahoy-articles.md>)

Topics: [Dependency injection](<https://devfeed.tech/topics/dependency-injection.md>), [Mocking](<https://devfeed.tech/topics/mocking.md>), [Polymorphism](<https://devfeed.tech/topics/polymorphism.md>), [mutation-testing](<https://devfeed.tech/topics/mutation-testing.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [dependency-injection](<https://devfeed.tech/tags/dependency-injection.md>), [interfaces](<https://devfeed.tech/tags/interfaces.md>), [polymorphism](<https://devfeed.tech/tags/polymorphism.md>), [testing](<https://devfeed.tech/tags/testing.md>), [unit-testing](<https://devfeed.tech/tags/unit-testing.md>), [unit-tests](<https://devfeed.tech/tags/unit-tests.md>)

## AI overview

This tutorial explains why Singleton implementations make unit testing and debugging difficult by hiding dependencies and tightly coupling code to a specific instance. It recommends creating shared objects in one place and passing them through constructors using dependency injection, while retaining the requirement for a single instance.

## Source excerpt

Often times there is a need to share a single object of a class throughout the code base. For example, we might want to store all online users in one central registry or share a central queue amongst all producer and consumer objects. We want to: ensure that exactly one object of a class exists. provide a way to get that object. This is a valid and a very common requirement but is often equated and related to a design pattern called Singleton. While they provide a quick and easy solution, singletons are considered bad because they make unit testing and debugging difficult. Brian Button has made some valid arguments against singletons: [Singletons] provide a well-known point of access to some service in your application so that you don't have to pass around a reference to that service. How is that different from a global variable? (remember, globals are bad, right???) What ends up happening is that the dependencies in your design are hidden inside the code, and not visible by examining the interfaces of your classes and methods. You have to inspect the code to understand exactly what other objects your class uses. One of the underlying properties that makes code testable is that it is loosely coupled to its surroundings. This property allows you to substitute alternate implementations for collaborators during testing to achieve specific testing goals (think mock objects). Singletons tightly couple you to the exact type of the singleton object, removing the opportunity to use polymorphism to substitute an alternative. He's absolutely right. It's very difficult to write unit tests for code that uses singletons because it is generally tightly coupled with the singleton instance, which makes it hard to control the creation of singleton or mock it. Recently I came across a project that made very liberal use of singletons. When I asked the developer about it, he said: "I know singletons are bad. But I needed a single instance of objects in all these cases and had no choice