It's hard to test code that uses singletons. Typically, the code you want to test is coupled strongly with the singleton instance. You can't control the creation of the singleton object because often it is created in a static initializer or static method. As a result, you also can't mock out the behavior of that Singleton instance.

If changing the implementation of a singleton class is not an option, but changing the client of a singleton is, a simple refactoring can make it easier to test. Let's say you had a method that uses a Server as a singleton instance:

public class Client {
  public int process(Params params) {
    Server server = Server.getInstance();
    Data data = server.retrieveData(params);
    ...
  }
}

This post lists 13 reasons for UML's descent into darkness.

Some of them are very valid points. Some of them are misinformed bunkum.

That UML is overly complex and difficult to learn and comprehend is a given. That the over-emphasis on selling modeling tools has clouded the just-sketch-it-at-the-whiteboard benefits of visual modeling is undeniable.

I updated this to run in Visual Studio 2008 and .NET 3.5.  It should work down to .NET 2.0.

The download is an attachment to this post.