[If you didn't understand the context. The post is about a (well known) IoC implementation.]

You see, using a container that loads different implementations at runtime based on a configuration file is just as awkward as hooking to constructors at runtime and returning a different implementation. The obvious way of doing things is simply having the tested code use an external object you can easily replace at runtime by simply sending in a mock that exposes the same interface.

But I guess I’m just making myself more enemies now so maybe it’s time to move on to a different subject.

Well, my bad, I thought we were discussing OOP. AOP is not exactly my cup of tea as you can tell. But that’s a whole new discussion…

Using AOP and wiring class initializers instead of simple polymorphism, seems to me like a You Ain’t Gonna Need It

Adding a testability aspect without changing your code is only one of many aspects you can add.
Others can be:
* security
* performance
* optimization
* accuracy
* data representation
* data flow
* portability
* traceability
* profiling
(See http://www.codeproject.com/gen/design/aop.asp)

And with the right tools, this can and will be easy.

In that case, I also don’t need to refactor in order to support writing to an SMS. All I have to do is run my application on a TypeMock-like framework and have the File class be substituted at runtime to a different implementation (one that sends SMS’s) before calling DoSomething().

Would you like maintaining code that hooks on class instantiators and replaces them at runtime instead of using plain old polymorphism?
But that it exactly what TypeMock does so you are saying that a technique no-one would want to use in production code is good for test code – why?

You are right, of course, about my DoSomething() that accepts IFile. But if you have a test that asserts that the File class is being used inside DoSomething() you have the same problem with encapsulation because once a different class is used to perform the same behaviour your test will have to be rewritten.

I have had this discussion over 4 years ago.
At that time it was a hot debate on the net.
OO and XP purist where debating whether refactoring code for testability was violating YAGNI.
The purist where saying:
“refactoring your code just to make it testable does NOT violate YAGNI because you need it “right now” for testing”

I will add: And Testing has business value.

But today: You don’t need to change your code to make it testable, so the whole issue is resolved.

About your code example: The way YAGNI works is that you start with the first example.
If and only if there is a new feature that we have to add, we refactor our code (extract and introduce a new method and implement the new feature – Some IDE’s will even find similar lines and do all the hard stuff for you).

So if in some time in the future you have to send all the messages to an SMS for example, then you can refactor your code. And by the way, in most cases you won’t have to change your tests, because you will leave the older implementation.

Also notice that in the second example, now all code that calls DoSomething() must know IFile. So you are actually lowering the cohesion (by having a less encapsulated system) in order to have a lower coupled system. This is a Design Decision that ‘Testabilty’ automatically makes for you.

Now let me ask you what is easier to maintain, this:

public void DoSomething()
{
File.WriteAllText(filename, text);
}

[Test]
public void TestWithTypeMock()
{
MockManager.Init();
Mock myMock = MockManager.Mock(typeof(File));
myMock.ExpectCall(“WriteAllText”);
DoSomething();
myMock.Verify();
}

or this:

public void DoSomething(IFile file)
{
file.WriteAllText(filename,text);
}

class MockFile : IFile
{
public bool _writeAllTextCalled = false;
public void WriteAllText(string filename, string text)
{
_writeAllTextCalled = true;
}
}

[Test]
public void TestUsingStandartMock()
{
MockFile file = new MockFile();
DoSomething(file);
NUnit.Framework.Assert.IsTrue(file._writeAllTextCalled);
}

Which one of these implementations would better survive a change in the name “WriteAllText”?

public void DoSomething(IFileSystem fileSystem)
{
fileSystem.WriteAllText(filename, text);
}