Isolating Dependencies Without Inversion Of Control

Question

I'm working on an enterprise application that relies heavily on message queues, com+, databases, httpcontext, static utility classes etc.

Since there's 600 projects in our system it seems impractical to rewrite to use inversion of control. Typemock claims they are the only isolation framework that doesn't require you to rewrite your code to use IOC.

Does anybody know how TypeMock implemented this level of functionality and if there are any alternatives? Even if I was to rewrite my application to use inversion of control I would have to write wrapper classes for message queues, httpcontext etc. To me that just sounds ridiculous, am I right or wrong to think that Typemock is the only viable option for my scenario.

Thanks

Answer 1

http://stackoverflow.com/questions/1073684/mocking-non-virtual-methods-in-c

Without digging really deep, the answer is AOP techniques. Since you can intercept method calls or alter method calls after-the-fact, this makes adding-in mock classes/instances very possible.

It's a clever use of AOP.

If you want to do this on your own (and I'm sure there are some pitfalls...), grab an open source Aspect weaver framework: http://csharp-source.net/open-source/aspect-oriented-frameworks

Answer 2

Most mocking frameworks do rely on some form of IOC. This is because IOC is in fact a good practice. Aside from testing, imagine you have a class that looks up a database connection (rather than injecting it), and now the class of database connection changes. You shouldn't have to recompile your code - you should just be able to change the injected dependency. From a testing perspective, you could do the same thing, inject a mock database service.

To get more toward your question. I would focus on gradually refactoring to an injection instead of a hard coded lookup framework. Start with the big pieces, like databases and other 3rd party services. As you refactor them out, you can use any mock framework (I've used EasyMock and I like it, but there are others - JMock, Mockito). These frameworks do not require wrapper classes, but generally rely on proxy objects. When you create a mock, you are actually creating a proxy (which is an instanceof the class type you are mocking).

Bytecode manipulation (Aspect Oriented for example, as Typemock uses) can be dangerous to rely heavy on. Often times you might have other tools that also manipulate byte code (code coverage tools frequently do this) and multiple bytecode manipulations can cause unexpected behavior.

Lastly, you can look at languages like Groovy. Groovy works well with Java (it gets compile to bytecode) and has mocking built right into the language. Some Google searches for mock objects with Groovy should return some good results.

Answer 3

You are right to think that TypeMock (or another similar mocking tool) is the only viable option.

It's always possible to use an AOP tool directly to provide isolation of dependencies, but the effort required to do so is significant, making it not viable in practice.

For Java, the JMockit toolkit enables isolation for all kinds of dependencies, without any necessary changes to production code.

Internally, JMockit uses the functionalities provided by the java.lang.instrument API. Basically, it allows methods/constructors to be redefined at runtime. Redefinition means the bytecode implementing the method/constructor is replaced. This can be done any number of times for the same method. Additionally, classes can be transformed at load time (i.e, any method or constructor defined in the class can have its bytecode changed just before the class is made available to the JVM).

Answer 4

If you've got a class like this:

public class MotherClass
{
 private SubClass _subClass;

 public MotherClass()
 {
  _subClass = new SubClass();
 }
}

public class SubClass
{
 public string SomeMethod()
 {
  return "Hello";
 }
}

It's without IoC. But with Typemock Isolator you can still replace it via:

    [TestMethod]
 public void TestMethod()
 {
  var fake = Isolate.Fake.Instance<SubClass>();
  Isolate.Swap.NextInstance<SubClass>().With(fake);
 }

And even swap out the result of the SomeMethod like this:

     var fake = Isolate.Fake.Instance<SubClass>();
  Isolate.WhenCalled(() => fake.SomeMethod()).WillReturn("Bye");