[Unit-Testing] How do you mock a Sealed class?
For .NET, you could use something like TypeMock, which uses the profiling API and allows you to hook into calls to nearly anything.
So, What is the best way you mock sealed classes?
Java answers are more than welcome. In fact, I would anticipate that the Java community has been dealing with this longer and has a great deal to offer.
But here are some of the .NET opinions:
Shim types provide a mechanism to detour any .NET method to a user defined delegate. Shim types are code-generated by the Fakes generator, and they use delegates, which we call shim types, to specify the new method implementations. Under the hood, shim types use callbacks that were injected at runtime in the method MSIL bodies.
Personally I was looking at using this to mock the methods on sealed framework classes such as DrawingContext.
I came across this problem recently and after reading / searching web, seems like there is no easy way around except to use another tool as mentioned above. Or crude of handling things as I did:
- Create instance of sealed class without getting constructor called.
Assign values to your properties / fields via reflection
- YourObject.GetType().GetProperty("PropertyName").SetValue(dto, newValue, null);
- YourObject.GetType().GetField("FieldName").SetValue(dto, newValue);
I generally take the route of creating a an interface and adaptor/proxy class to facilitate mocking of the sealed type. However, I've also experimented with skipping creation of the interface and making the proxy type non-sealed with virtual methods. This worked well when the proxy is really a natural base class that encapsulates and users part of the sealed class.
When dealing with code that required this adaptation, I got tired of performing the same actions to create the interface and proxy type so I implemented a library to automate the task.
The code is somewhat more sophisticated than the sample given in the article you reference, as it produces an assembly (instead of source code), allows for code generation to be performed on any type, and doesn't require as much configuration.
For more information, please refer to this page.
The problem with TypeMock is that it excuses bad design. Now, I know that it is often someone else's bad design that it's hiding, but permitting it into your development process can lead very easily to permitting your own bad designs.
I think if you're going to use a mocking framework, you should use a traditional one (like Moq) and create an isolation layer around the unmockable thing, and mock the isolation layer instead.