Design and Testability – YAGNI

Failing to take the bait, or perhaps that’s what I just did 🙂

I have no answer to the quiz. How can I know that the second code snippet is not the implementation of the first?

Joking aside, could it be we disagree because we have different understanding of what a testable design is? I have seen a lot of arguments flying around, but no code. No design.

Then I got this feeling that you design frameworks, while I design applications. Different worlds, different rules.

Maybe it’s time to discuss actual code?

Balancing Maintainability, Readability and Testability

I thought a lot about your YAGNI argument against using polymorphism to insert mock objects in tests. I think you are forgetting that unit tests are a part of the system’s code and that their readability and maintainability is just as important as that of the rest of the system. This is why inserting access points in my design for tests is not a YAGNI – I need it for the tests.
Your argument is that I don’t have to use polimorphism because TypeMock can replace concrete calls at runtime – but that is true not only for unit tests. Using reflection I can replace concrete calls at runtime wherever I wish but this is obviously a poor design decision. So why are tests any different?

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”?

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

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.

🙂 Nice.

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 🙂

It is a good one indeed. It has little to do with designing for testability though.

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.