Does C# 4.0 Make Poor Man's Dependency Injection Less Poor?

This post by Jimmy Bogard talks about why Poor Man's Dependency Injection is bad. In that post, Jimmy talks about how Poor Man's DI makes dependencies opaque. With C# 4.0 and optional parameters, you can do Poor Man's DI in a way that makes the dependencies more transparent. Consider the following class:

public class MyClass
{
  IDataReader reader;
  IMessageSender sender;        
        
  public MyClass(IDataReader reader = null, 
                 IMessageSender sender = null)
  {
    this.reader = reader ?? new DefaultDataReader();
    this.sender = sender ?? new DefaultMessageSender();
  }
}

Does this approach make Poor Man's DI more palatable or should it still be avoided?

Now I Get It...

Now I see why all of the cool kids speak so disparagingly of developers who don't use ReSharper. Wow, that is one sweet tool!

State Based Testing Versus Interaction Based Testing

When I first learned about unit testing and using mocks for interaction testing, I thought it was incredibly cool. Over the past few months I've seen some people write that state based testing should always be favored because interaction based testing requires knowledge of implementation details. I accepted this as true and started to worry that I relied too heavily on interaction tests. However, I recently began to wonder if interaction tests really do require more knowledge of the implementation details than state based tests. Obviously I am not talking about the case of testing a return value. That is the simplest case and really doesn't require any knowledge of the implementation. What I am talking about is doing state based testing by checking a property after a method is run. Is saying "I know that my class has a property X and I know that running Foo() will result in X being equal to 3" so different from saying "I know that my class has an interface that is used to access the database and I know that running Bar() will result in Baz() being called on that interface"? Some might say that the difference is that the property X is part of the public interface and the interface for data access is not. However, if we are using dependency injection to provide the class under test with its data access object (and we all agree that we should be doing that, right?) then the fact that this class needs, and therefore uses, an implementation of IDataAccess is publicly known.

Maybe I am thinking about it the wrong way but I'm no longer worried about my use of interaction based tests.