Donut Oriented Programming: DOP is a required discipline that you need to adhere to when your app will use VERY slow internet connection, such as in Cambodia and some other developing countries. Every action on the application that requires a roundrip to a server on the internet, should result in a donut being displayed to indicate that something is going on.
In "traditional" OOP, you advertise your class required dependencies via constructor arguments:
public Foo(IOutput output, ILogger logger, ...)
Typically, the first few lines of code will check that these dependencies are not null.
Optional dependencies may be provided as properties, which you can leave unset (null).
Internally, in order to avoid a multitude of conditionals checking for nulls, you might have your own "null" implementations of the dependencies' interfaces (i.e. NullLogger which does nothing). This way the code is more readable, and you can always assume the dependencies are non-null and you'll never get a NullReferenceException ;)
One problem with property dependency injection is that you can't readily tell which properties are dependencies, and with constructor arguments, you cannot specify which ones are optional (can be passed null OK).
I think a much more consistent approach, and one that would integrate very well with the nullable value types functionality in .NET, is to introduce the concept of a nullable reference type:
public Foo(IOutput output, ILogger? logger, ...)
What this tells the caller, is that the first argument is a required dependency, while the second can be null. I believe the .NET framework should go one step further and give the implementer a null implementation of the interface or abstract class if the argument is null. This way, you get rid of all nulls in your apps.
You can also avoid depending on properties to advertise optional dependencies (and an associated custom attribute such as MEF in order to indicate it's a dependency and not a regular property).
I've argued in the past that this theoretical discussion is utterly useless. In my experience you need slightly different things from your test doubles at different times and depending on the scenarios and what you care about testing in a particular test.
If you're not using any mock/stub framework, you're typically creating manual test aids that morph (so that you can reuse them) as your tests evolve, and end up encompassing a mixture of a fake (i.e. you might put in an in-memory implementation), a stub (flags to tell you whether given members were called) and a mock (you might provide delegates to execute when members are executed, so that you can throw/callback/whatever). I've done this countless times before jumping to a framework/library to help me with this, and I know this is the continuum most developers live in.
Yet, we still see discussions like Rhino Mocks 3.5 Design Decisions: The role of Stub vs. Mock, were the user is asked to make a choice that he will seldom understand without reading the theoretical background. This is counter-productive IMO.
Compare the original two versions with Moq's version:
public void When_user_forgot_password_should_save_user()
{
var userRepository = new Mock<IUserRepository>();
var smsSender = new Mock<ISmsSender>();
var theUser = new