Michael Feathers

Singleton is Incompatible with Unit Testing

Is the Singleton design pattern incompatible with unit testing? I think it is. Singleton assures us that our program will have only one instance of a particular class and that there will be a global access point for it. Put those two ideas together, and what you have is a global variable that can't be replaced. Doesn't sound so bad? Well, try this out: write a set of unit tests which exercise clients of that variable. If one test modifies global state, and another uses it, you could have one hell of a debugging chore when your tests fail. I won’t elaborate on the pain here. If you’ve ever encountered it, you know about it.

The Singleton pattern allows only one instance of each singleton class in a system. In Java, that’s one per classloader or JVM, and in C++ it's one per executable.  That's fine when you have just one system, but each test is a little "system" too; and if each of the tests needs to use a particular singleton, they can't be complete or independent because the singleton, through it's creation characteristics, has defined the scope of the "system": it's the JVM, the .NET runtime, or the interpreter.  When you think about it, isn’t it a little arrogant for a class to decide that?

One of the easiest ways to get past the impasse is to break the singleton property, the requirement that there can be only one created instance.  If you can provide some way to set a singleton’s instance, you’re on the path to create a fakable singleton, or fingleton.  You can use a configuration file to dynamically load a fake for testing, or write a static setter to set the instance. In some languages, you can use reflective tricks, or even conditionally compile the setter method so that it is only available when you are testing, but in the end, you are able to create more than one instance of that class: what you have is a fingleton, not a singleton.

I think that many of us have known that Singleton is broken for years, but we just haven't stated it out loud. There are always the little exceptions. For instance, singletons cause no trouble at all if we can’t affect state through them, but cases like that don’t come up often. If you have an immutable data structure, it's overkill to make it a singleton. Likewise, if you have something stateless like a factory, well yes, it’s great to have one distinguished instance, but what do you do if you need to mock it? There’s that singleton property, getting in the way again.   

Faced with singleton's troubles, many people turn their singletons into fingletons and attempt to protect their instances as best they can.  There are many protection mechanisms, but it seems that as they become more elaborate, the object becomes harder to use in a testing situation. Sometimes the simplest answer is the best answer: supply a static method on your singleton called setTestingInstance.. unprotect your constructor and introduce an interface.  Create mocks for your "singleton".. eventually you may be able to pass it around by reference rather than using it globally. 

Yes, there are cases where you might want more protection than this and in those cases you should add whatever protection you feel you need, but let’s face it, on most projects if your teammates can't refrain from calling a static method named setTestingInstance in production code, your project is probably in trouble no matter what you do.  On the other hand, if they can, it's easier to keep your software testable, correct and maintainable.

Sending People Home

A few years ago, I was helping a team transition to agile. They were in pretty sad shape. When I got there, they couldn’t build their software. Millions of lines of C++ code and every time we tried to build it, it failed.

 I sat with two or three other developers and worked diligently on the build. The team had about twenty people, and sure, they could’ve worked on some other tasks, but really the build is the heartbeat of a project. If you don’t have that fundamental feedback mechanism in place, there’s very little else that you can do that’s productive. In fact, most of things that you can do without the feedback of a build are counterproductive.

 A friend of mine, who was coaching the customer team noticed that I was pretty much ignoring the rest of the developers and he asked what they should be doing. I said “send them home.” “You can’t send fifteen people home!” he said.. and I knew what he was talking about. The team was under pressure, and politically, it would’ve been a nightmare. At various levels of the organization the only reality that could be heard was “these twenty developers are doing everything that they can to get past the build problem.”

It took three days and three people to get the build going. When we did, the rest of the developers started taking on tasks, and making progress, but I still regret the fact that the other developers had to appear busy during the process.  It would've been better for all concerned if they went home.

Things like this fascinate me.  There are some ideas that you can communicate effectively in organizations and others that you can't.  In this case, there was clearly a manager who knew that twenty people couldn't work on the build at once, and that there was nothing productive the other people could do.  But, the fact that he knew it didn't help. 

I think that the real issue is the reporting hierarchy.  Do people at each level have the trust of the people they report to?  If they do, the person closest to a problem can make a call and not be worried about people above second-guessing it based upon incomplete information. 

It's a tough thing to coordinate.  The further a person is from a problem, the more apt they are to think that they see a better solution than the people who are closer.  In many cases, it's an illusion based on lack of information.  This is part of something that I sometimes call social signal loss; it's pervasive in human systems and I suspect that it implies that sometimes you can have too much transparency.

 

Conservation of Seriousness

I'm continually amazed at the cultural differences that I encounter across companies. I visit one company and discover that, despite the fact that they develop mission-critical code, they have a rather loose and light-hearted culture.  A few weeks later, I visit another company and I discover that although what they are writing is important, it's far from mission-critical, yet they attack all aspects of their work with grim-faced seriousness.

The differences are astounding. At first I thought that they were more correlated with company lifecycle than application domain. Startups tend to a have looser culture.  Companies that have cornered a market tend to grow a bit more rigid.  Mature companies that are being attacked on all sides by competitors tend to be incredibly seriousness – about everything. Yet, despite this loose correlation there are plenty of exceptions. At this point, I think that company leadership has a lot to do with the feel of a company. And, sometimes, it's local leadership. I've visited companies that have radically different cultures at different sites.

One thing I've noticed about companies with "serious" cultures is that they are seldom serious about everything. In one case that I'm thinking of, a company with rigid plans for everything and incredibly comprehensive processes, I noticed there was a lot of passive noncompliance -- but it was subtle. The company had mechanisms in place for everything, including taking care of visitors, but every time I visited, one or another mechanism was slightly broken. The people involved would shrug and apologize. It seemed that they just couldn't take everything seriously. I notice the same thing in the software realm. Teams which are very serious about process and documentation are often less serious about their code. It isn't a perfect correlation, but visit enough teams and it is noticable. It makes me wonder whether there is only a limited amount of seriousness possible in any organization.

Before I go further, I want to explain what I mean by seriousness. We have to be serious about what we code, and how we code. Software development is serious work. It's easy to make mistakes that can have disasterous consequences. The seriousness that I'm talking about, though, is lack of levity. There are some places where you simply never see people laughing or joking with each other, or reflecting less than seriously about their work or their situation. It would be seen as evidence of lack of Seriousness (with a capital 'S') and grounds for shunning.

A few years ago, I read a story about a government worker who was playing Solitaire on his computer during his break. A boss, a couple of levels above him was visiting the office that day and he made a note of the employee, spoke to his supervisor, and had him fired the next day. I forget now whether there was an actual policy against using a computer for personal reasons during a break, but for the point I'm making it's pretty much immaterial. It was apparent that the boss wanted to communicate seriousness, and he did so. I'm just not certain that it ended up having the effect that he expected. If conservation of seriousness is true, the employees just ended up being less serious about something else.

I think there are things that we have to be deadly serious about, but they are narrow. I've never been to NASA, for instance, but I would expect them to be deadly serious about the flight control software for the space shuttle. I've read about their development process, and it seems serious, but I would be surprised if there isn't a bit of levity. In fact, I'd be scared if there wasn't.

What does this all mean? If conservation of seriousness is a real thing, I think that it means that if you are a manager or an executive of an organization, you really have to be selective about what you denote as serious. It's important to be very specific. Otherwise, people will choose what they are serious about and it might not be the same as your choice.

 

Dependency Injection in C++

Last week, I was working with a C++ team and they needed some testing help so I pulled out my bag of tricks. I showed them how they could make their code more testable by externalizing object creation and adding constructor parameters. They were a little shocked that I would add constructor parameters just to make code testable, so I asked whether they’d ever heard of dependency injection (DI). My question was met with silence, but frankly I expected it. In my experience, few people in the C++ community seem to know about dependency injection. Part of this is understandable. C++ has been growing away from Java for the last seven or eight years. There used to be a rather large overlap between C++ and Java programmers, but that’s changed. The Java community has spent a great deal of time developing frameworks and tooling to advance their practice, but tooling is difficult in C++ so that community has been spending a great deal of time pushing templates as far as they’ll go.

I was talking to Scott Meyers at a conference earlier this year and he said that he felt that the real fork in the road was ease of parsing and tractability of analysis; that C++ was developed before people realized just how valuable those attributes were in a language, and as a result, the things that people do with reflection and tooling in Java are now attempted with template meta-programming because it seems like the easiest avenue. It doesn’t look all that easy from where I sit, but it does look like a committed course of action. The C++ and OO communities don’t seem to have much in common any more in the solution space, but they do have some common problems. 

Testability is a tough taskmaster. It’s hard to write code that is easily testable unless you’re very diligent. When we work in statically typed languages, code is coupled by default. If a class uses another class, you have a compile-time dependency. C++ does have a sneaky way out of this problem. Templates are essentially un-typed so you do have some leverage before they are all instantiated to type-safe code, but regardless, testability is hard. If a class of yours uses vendor software that you can’t really run in your test environment, well, you need an adapter to mock it out. If you didn’t build one in, you’re left with the task of refactoring one in.

In the Java community, dependency injection has evolved as a way to solve this problem. The core idea of dependency injection is simple: object creation is a separate concern. If you push object creation into a separate area: an über-factory, you can make your code more flexible and more testable. Most descriptions of DI dwell on XML configuration, but it’s really simpler than that. Essentially, a DI system has a big bag of types and you go to that bag (factory) and tell it to make you an object of a particular type. The bag looks at the types and sees if it can create the object you want. It uses reflection to examine constructor arguments, setters on classes, etc. If it finds that it can, it will give you the object you asked for. If you want an instance set up for testing, you alter the types in the bag. 

C++ makes this a bit difficult. There’s no general way to determine the arity or arguments of a constructor at compile-time so that standard tricks for mimicking reflection with templates don’t work. There may be a way to do setter-based injection, using some of Andrei Alexandrescu’s hierarchy generation techniques, but I’m not sure yet. 

In any case, it seems that to do DI in C++, you have to place constraints on the classes you create.. you have to make them inherit from some other class, use macro preregistration or a metaobject library.  The one C++ DI framework I've heard of, QtIocContainer, seems to bring along some of those constraints.    Maybe they are inevitable.

The thing that I do know is that it would be useful to have more awareness of DI in the C++ community. I may be overestimating it, after all, the C++ community has not had nearly as many widespread, crippled vendor APIs hoisted upon them.. APIs which make testing a real bear, but I’ve seen a few, and I suspect that DI could help.