TypeMock, Static and Dynamically Typed Languages

is talking about the evils of type mocking in a strongly typed

Here is the deal. In a strongly typed language we
use type to specify a contract for a message (where sending a message equates to

calling a method). There are benefits to that, in that we can check at
design time that messages passed to us conform to the  contract that we
specified. But the danger is that we are limited to one caller if we use a
concrete type.

Let’s imagine that we have a calculation engine and we are
happy that it performs a calculation on type A for us satisfactorily.

Let’s now imagine we are asked to perform the same calculation on Type
B. We only accept arguments of type A, which prevents us from doing this, so
expanding our software to furnish new capabilities becomes hard as we would have
to change existing code. That
entails risk and the cost of regression
testing the calculation engine.

In a strongly typed language we overcome
this issue by polymorphism.

We extract the characteristics of the type that our calculation engine
needs to talk to into a base type and derive types that we pass to the engine
from that type. So we would have a base type A and derive types that we can
calculate, say B and C, from this. Now anything that is a type A can be used
with our calculation engine. Usually we prefer to use an abstract type for this
base type
(in implementation terms an interface or an abstract type). Now we
have made our code closed to modification but open to extension. New consumers
can use the services of the calculation engine without changing the calculation
engine code. Because we don’t change the calculation engine we remove risk. This
is an example of the strategy pattern, and
is often referred to as the Hollywood Principle:
Don’t call us we’ll call you because we call the consumer rather than the other
way around.

TDD drives
architectures that depend on abstractions because you want to test your unit in
isolation so you want to be able to provide a Test Double at run time
for anything the unit under test depends on. To do this you implement the
strategy pattern so that you depend on a polymorphic type. If you aggregate the
dependency into your class then you tend to inject the abstract type in the
constructor or a setter. This composition from abstract types is called
dependency injection or inversion of control (depending on quite how you
implement it).

Type Mocking allows us to avoid this need to provide an
abstraction when testing by using the .NET profiling API to replace a type at
run time with our Test Double. While this works, it does not push us in the
direction of depending on abstractions so the design effects of the TDD approach
are not enforced. That’s why type mocking tends to be considered

typed languages
, like Ruby, don’t have to worry about depending on abstract
types because of duck typing. Duck typing
means that all that matters about the object passed into a method is that it
supports the messages sent to it i.e. implements the method. For example if we
call the GetCost() and GetRate() methods on the argument to our calculation
method, all that matters is that the object we pass in supports those methods.
Any object that has those methods is a valid parameter. In other words because
dynamically typed languages do not need to declare that they are of a given type
they are inherently able to support polymorphism.
This means that dynamic
languages do not need to explicitly use the strategy pattern.

Of course
you still need to make sure that you favour composition over inheritance,
because otherwise you will not be able to swap.

The down side to
dynamically typed languages is that you do not find out whether your type ‘is a’
until run-time when you try to exercise the method and discover it is not
present. Tests are the only solution to this problem, and they need to be
customer tests because the problems only show up at integration. Of course we
want to exercise all our code, but the downside here is that the issues may be
more costly to fix if the feedback occurs later in the development cycle. The
upside here of course is that a dynamically typed language would not need a type
mocking solution, nor would it find it dangerous if it used one, because it does
not need to have polymorphic behaviour declared.

The trade off here is
between the need for the statically typed developer to make bets about where
extension is necessary and use abstract types, and the danger that the
dynamically typed language developer either fails to check all the paths through
their code or does so at a point when the feedback leads to costly refactoring
or redesign.

To return to the issue of the day. We are about to purchase
to use its type mocking facilities for one key scenario: working with legacy
code (where legacy is defined as does not support tests). Sometimes you are not
in a position to change all the code to work with abstract dependencies and need
to lean on something like Type Mock to get you through. It’s called being
pragmatic. But be aware that TypeMock is creating technical debt,
and you are going to have to pay up, because living on credit from TypeMock will
hurt in the long run.

This entry was posted in Computers and Internet. Bookmark the permalink.

47 Responses to TypeMock, Static and Dynamically Typed Languages

  1. Unknown says:

    wow gold wow gold eve isk wow power leveling wow power leveling wow power leveling wow power leveling warhammer gold warhammer power leveling bestchina traveland ugg bootsor ghd straighteners

  2. 旺立 says:


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s