I think labelling the ALT.NET community with such a wide
brush, based on one person's comments, is more than a
little unfair.
Similarly, would you like it if people dismissed your
comments on TDD because you are employed by TypeMock?
"The simplest thing that WORKS" is a better way of
phrasing it ... the important word is WORKS. Creating
poor code because you are lazy needs to be an explicit
design decision. Creating excellent code that needs
TypeMock to be tested is also a design decision.
Sometimes you are going to have to bite your lip on this
kind of comment Roy, taking the silver shilling does
imply a degree of abstention from these kind of debates
... let your satisfied customers do the justifications
for you, I'm sure there are more than enough that have
no axes to grind and therefore can argue with a degree
of separation.
Casey - I would have written the same think had I not
worked in Typemock. The fact that I'm there made me see
things from a different perspective and I don't like
what I see.
Biting my lip? This has nothing to do with Typemock as a
product, but the community as a community.
This is just a tip of an iceberg I've been watching grow
over time in many discussions.
There is no room for dogamtic development, totally
agree. On any side.
But again, generalisations help nobody.
I think you may just have to accept that some ALT.NET
people (and probably many others) see TypeMock as a
product that encourages bad code practices. Your point
of view differs. Some people see it as a useful tool
should they need it.
Obviously people writing other mocking frameworks are
going to have a different philosophy on mocking
practices.
I agree that it seems a bit harsh to condemn the
entirety or Alt.NET for one person's comments. Alt.NET
is full of many people with many different opinions.
Some are dogmatic about their opinions, others aren't.
The commonality is everyone is looking to improve how
they design and develop software.
I'm not saying Alt.NET should not fight within
themselves; just the opposite. I believe a good, honest
debate is healthy. But I find the blame-the-community
tactic a bit like the nuclear option: you only hit it
when you are either desperate to win the debate or out
of ideas. Either way its not advised as it does more
harm than good.
Just my opinion though.
Chad:
"But using TypeMock as your primary mode of enabling
your coupled/opaque design is a recipe for long-term
disaster."
That's the think. I'm decoupling the idea of using a
test framework from how I design things. Seperation of
concerns and decoupling is a good thing, but how is
wrapping X amount of classes easier than using a
product? that is beyond me.
I'd have no problem id he had said "Sure, it takes
longer and its harder to refactor for testability, but
that is a price worth paying for a longer lasting more
robust and maintainable codebase int he long run. But
that is not what was implied.
Throwing the axe at the community is something that is
warranted , looking at the mainling lists and from
discussions in the various alt.net conferences.
people have become as dogmatic about doing DI, IoC and
interface based stuff like the old "Wise" men used to be
hooked up on deep inheritance hierarchies.
We are all going too deep in the other direction.
I am neither desperate, nor am I trying to "win" any
debate. I'm saying what I feel and something that I
think not many people are aware of - ALT.NET is not the
end all be all answer to everything. it is a quest for
finding better alternatives. along the way people have
gotten stuck to some alternatives and are even afraid to
try others with lots of FUD.
One comment doesn't make a trend. If this is a broader
community problem, let's see some more examples.
Good design transcends good tooling. To build a design
that rests on a tool is foolish.
I can use Moq or Rhino Mocks to facilitate a testable
system which can easily be tested using another
framework, because it's built in a decoupled fashion.
However, if I were to build a system in such a way that
the only way to test is TypeMock, then I'm tied to it
and that isn't good for future maintainability.
Rhino or TypeMock one day will stop being maintained,
but the first setup will allow me to swap frameworks,
while the second wont.
Roy, if anything you are too easy on the Alt.Net folks.
I'm hearing a lot of defense of dogma from that
community and little discussion of trade-offs or
pragmatic reality. Just look at the comments on your
very mild post here. Notice how your commenters from the
Alt.Net community want to deny you the right to dissent
from them ("taking the shilling" for pete's sake?!?) and
call you names like lazy or imply that you're
disconnected from reality (I'm looking at you, Chad).
I notice that they seem kind of desparate to dismiss you
without actually bothering to take on your actual point.
That's a pattern I've noticed coming from that quarter
in the past. It seems to me that the Alt.Net community
is willing to tolerate only approved forms of dissent.
It's ugly, cliqueish and off-putting behavior like this
that taints the community. I find that I'm less and less
willing to listen to them at all as time goes on.
@James Once you introduce a technology or framework it
isn't going to magically disappear. You still have it.
Five years down the road you can still use it. Just as
folks are still using NDoc today.
@Roy
I'm not coupling that to a test framework, I'm saying
that TypeMock's primary purpose/goal/feature is not
inline with those things. Or rather, it's advantage/edge
over other testing frameworks is nil if you're designing
thigns correctly.
TypeMock has a purpose and a very good one, and so I
don't slam TypeMock. I do slam people who will abuse
TypeMock to allow them to persist in poor system
designs.
I believe this was Daniel's point: Why go out and buy a
new tool when the free one you're probably already using
will help you work towards a better design anyhow?
If you already have TypeMock, then the question switches
to: How can I best resist the temptation to abuse
TypeMock's features and stick to doing good design?
If you have no testing framework at all, starting from
scratch and you're aware of how TDD drives better, more
decoupled design, why spend money and buy a tool like
TypeMock when the free/OSS ones do exactly what is
needed?
I don't see the duplicity in Daniel's thoughts at all.
The simplest thing is to do the design right in the
first place, using TDD, using a free/OSS tool. If there
are other restrictions or complications that require you
to purchase a tool, then yes, TypeMock would be first on
the list. But that's not necessarily the 'simplest'
thing that can work. Buying a tool and incurring cost is
not the simplest thing in most cases (sometimes it is,
but generally not).
One more thing, sorry for the double post:
I agree ALT.NET isn't the end all be all. It will fade
with time, but the principles it espouses are both very
old, and tried/true/proven. These include Agile
Manifesto-type principles (people over process, etc),
Uncle Bob's SOLID principles of object design,
composition over inheritance, etc. These are (relatively
speaking) VERY OLD concepts, but they are seemingly NEW
to the .NET world which is why ALT.NET seems to be the
subject of much ire and disgruntlement.
So if you want to call a focus on SOLID principles,
Composition vs. Inheritance, Communication + Trust
(Agile) concepts as 'dogmatic', then I guess I'm guilty,
but I know I'm right because I'm following the path that
many of the most well-respected luminaries in the
business have paved for us and I'm willing to put their
credentials up against any of us (certainly myself) here
any time.
I think the original post was poorly named, it shouldn't
have been about "mocking static dependencies". The
author made a foregone conclusion that static
dependencies are a good idea.
They're not.
Static dependencies are opaque, and clients of the class
cannot see what the class needs for it to work properly.
Ray Houston and I recently did a screencast on
eliminating static dependencies to try and illustrate
the problems of static dependencies. There's a clear
difference between encapsulation and subterfuge.
It's unfortunate that the conversation became a tool
conversation, rather than a design conversation. That
would have been much more rewarding.
Love the title. :) I wouldn't hold up Daniel's behavior
as a shining example of any particular community. I've
found in previous conversations that he's willing to say
almost anything to sell his tool (take note, Roy) and he
has no moral issue with bashing a product (Rhino Mocks)
for its "advanced" features in order to highlight his
product's simplicity, only to turn around and implement
the same exact features a few weeks later. But until he
actually gets a chance to implement the functionality in
his product, he will argue his position until he's blue
in the face.
While I agree with the two-faced diagnosis, I disagree
with the broad sweeping association with ALT.NET. That's
a sensationalistic low blow and undermines both your
credibility and the credibility of TypeMock. Be careful.
Just because Daniel stoops to such tactics doesn't make
it right.
@chad
"...TypeMock is all about keeping your existing coupled
design and using magic to be able to test it"
No, I believe Typemock is about providing the most
capable and feature rich mocking framework possible.
Typemock would never force you into making design
mistakes, in the same way it would not stop you from
them.
Blaming Typemock in poor design decisions is for me the
same as blaming Visual Studio for the bugs in your
code's logic - having a tool that gives you the
capability to create something doesn't mean the tool is
to blame when you create a monster.
Just my 2c...
I think Chad is probably the one that really got what I
meant with my phrasing.
When you talk to people, and say "statics are bad", they
will use TypeMock as an excuse as to why they are not
really bad, as you can still "mock them".
They are bad, and the one to blame in this case is
WCF/ASP.NET poor design for testability. In that regard,
they are like your example legacy coupled code.
What I meant to show, is that even in the presence of
such a design, you don't have to immediately fall to
using a tool to overcome a bad design. You can actually
improve your design by decoupling it from bad decisions
from others.
Bashing the ALT.NET community was unnecessary. I'm not
even an active member of it by any means (compared to
most).
>>in the same way it would not stop you from them.
<<<
And that is the key objection most have, beginners will
take the path of least resistance, and learn bad
techniques. You cannot make that mistake in any other
mocking framework.
If TypeMock had a Strict option that would not let you
mock statics/etc and it was on by default ... I think
most objections would be gone.
Then it would come down to price and features alone.
Roy,
Much as you may be getting some grief on this post, I
think I tend to agree with you on your observations.
As I understand ALT.NET and tooling its about being open
to considering alternative and how those alternatives
would potentially allow faster/better/easier/cheaper/etc
delivery of product. Different situations mean different
tools deliver different benefits.
IMO, I am starting to see a kind of "settling" on
recommending/using/adopting a standard set of tools and
practices, almost without actually taking the time to
consider if those tools and practices are really
appropriate. ALT.NET has become standardized.
Just my 0.000002
@Casey
Indeed, beginners will make mistakes, so it's our duty
as the seasoned veterans to show them the best known
methods and give them motivation to do the right things
right.
As part of this role, we shouldn't get fixed on dogma to
the point of excluding viable alternatives. Hearing
people I appreciate in the community preach that a tool
is for lazy developers or that it promotes bad design
smells to me like stagnation.
My take on the entire situation: Powerful tools don't
make bad design. Bad designers make bad design.
Discrediting an excellent tool like I believe Typemock
is because of these reasons is akin to throwing the baby
with the bathwater.
@Chad: "How can I best resist the temptation to abuse
TypeMock's features and stick to doing good design".
Only those that are "pure at heart" are able to muster
their strength and rise above the evil of Typemock.
You are helping Alt.Net retain an elitist and yes,
dogmatic image. Alt.Net is becoming a fortress sealed
from the inside, and its inhabitants are standing on its
towers, looking down on the commons outside, and saying
"why won't they just come in?"
>>ALT.NET has become standardized. <<<
In so far as most ALT.NET people would use any one of 3
or 4 mocking frameworks, including TypeMock where
appropriate ... that could be said to be true ... weird
view ...
Apparently standing up for quality and continuous
improvement in software is a bad thing and makes me
'dogmatic'.
And also, apparently standing up and calling B.S. to
TypeMock's marketing message about 'so you don't have to
refactor for testability' and the productized
sub-optimization of software makes me 'dogmatic'.
If I saw someone wasting time at work playing solitaire
and called them on it, would you call me dogmatic for
that too?
Also, for the record, RM is not a 'standard', it's been
the only serious mocking contender for a long time.
TypeMock is relatively new and spouts a marketing
message contrary to the original purpose of mocking
which offends the community.
Moq is very new and, at least in my case, I just haven't
had serious time to play with it. But I'm sure I'll like
it when I do.
More to the point: I'm currently working on a skunkwork
project trying out messaging-based architecture a la
Greg Young's DDDD series of blog posts and I'm trying to
do the whole thing without the need of Mocks at all (but
still staying true to SOLID principles, etc).
If I were really dogmatic, I'd say ONLY USE RHINO.MOCKS,
but I don't. I've even supported the use -- in this very
comment thread even -- of TypeMock for specific
situations where it is the only, and best answer to a
problem.
@Chad
"TypeMock is all about keeping your existing coupled
design and using magic to be able to test it."
I think that's an incorrect statement.
Chad:
"TypeMock is relatively new and spouts a marketing
message contrary to the original purpose of mocking
which offends the community."
it's been around for longer than you think (two years?
more I think).
I do believe that the "marketing message" should be
better and less divisive. eventually we all believe in
many of the same qualities, but sometimes have different
ways getting there.
If you are not careful enough and can shoot yourself in
the foot, the less shotguns you have around the house,
the better.
That said, you may have a big, ugly, old contender where
you really need the biggest shotgun you can get. But
you'll be giving it to your very best guys, not to the
newbie soldier.
Better to teach the newbies how to shoot smaller
objectives with a regular pistol first (the whole point
of Pablo's post on mocking WCF static context).
Some may say this sounds somewhat paternalist. I think
that's pragmatism.
Somehow the phrase "running with scissors" springs to
mind when I think of the ALT.NET community. For some
reason though, if your specific brand of scissors is a
poor design (however you got there) then the ALT.NET
community seems to view that as inherently evil,
regardless of the actual business decisions involved. I
think Roy's pragmatic approach is the only one that
makes business sense since the dogmatic approach of many
ALT.NET proponents fails to take into account the time
value of money. Spending less time now to fix a design
deficiency may cost more over the life of the project,
however that must be weighed against current cash flows
and the actual current cost savings versus the
anticipated future cost savings which may or may not
materialize.
>>For some reason though, if your specific brand
of scissors is a poor design (however you got there)
then the ALT.NET community seems to view that as
inherently evil, regardless of the actual business
decisions involved<<<
I think it more appropriate an analogy, that ALT.NET
people would prefer that if you are going to run with
scissors, that you do not point the scissors towards
yourself, in the hope that you won't fall.
Some products, and some approaches to development very
firmly point the scissors the wrong way around. Then you
just have to pray you don't stumble.
@Casey
"I think you may just have to accept that some ALT.NET
people (and probably many others) see TypeMock as a
product that encourages bad code practices. Your point
of view differs. Some people see it as a useful tool
should they need it."
Totally agree, I think the main problem with the
TypeMock discussions was that as a group we didn't start
out which this in mind.
I must admit that I've had a few discussions with
colleagues who are getting a little bored with ALT.NET.
The problem is that it seems like the same old arguments
go round and round and maybe just admitting that there
is no right answer is enough.
Plus opinions change, I have a lot of success with both
interface first Rhino Mocks style and with TypeMock...I
don't argue that either can work. Plus if I want to
switch from TypeMock to Rhino it's not gonna be a big
deal, at worst extracting a few interfaces and injecting
in places where I haven't so far. And if I found that I
was missing interfaces that did prove to be useful, and
if I thought this was down to TypeMock, then TypeMock
goes out the window and I never use it again...
I enjoy discussions about other issues, like how mock
first development aids design, but to be hones the best
discussions on those topics seem to happen outside of
ALT.NET (or outside of the forum at least).
@Chad
I think one thing to remember is that a lot of us have
read Uncle Bob and other authors so it's not that we
don't get it, it's just that we draw the line
differently on particular parts. That's good, not least
as no two authors agree anyway.
Plus even if I do like Uncle Bob and draw on his work I
don't necessarily draw equally on it all, for example
the package design content.
So to be honest I do think ALT.NET discussions can be a
little dogmatic, and I think that some of it does come
down the fact that people can come accross as thinking
that anyone who does not do exactly the same thing as
them is lazy/designs badly/loves coupling/doesn't buy
into continuous improvement or whatever.
I find this thread a reason, why I have been so turned
off from Alt.net and yes I know this is not fair but
every time I find a post about alt.net it is riddled
with name calling.
I've never used TypeMock, nor any mocking approach for
my unit testing. And yes my unit tests have over the
years become system tests encompasing many factors. But
in the end I am testing that my changes did not break my
system so I have been ok with this.
The idea behind type mock is appealing. So yes I loose
the ability to decouple my Business Object Manager whose
sole responsibility might be to cordinate persistance
with a database from the data access layer under it, or
from the error component. I have spent many years trying
to hide my Error handling implementations in the event
we ever need to change the approach, while waiting for
the need, I decided to stop trying to abstract away the
abstraction layers.
Just for the record I am not always advocating coupling
a system. Particularly when you have a complex system
made up of many smaller subsystems. Decoupling them
allows the subsystems to grow and expand easier.
In some cases simplicity might be desinging for
testability; however, simplicity could also be measured
in how difficult it is for an entry level developer to
read and maintain the code. Simplicity could also be
measured in the number of lines of code one has to read
or the number of places on has to look to figure out
what's going on.
-josh
1) Communities should be generalized. It helps them
bond.
2) I've used typemock and rhinomocks both in the same
project, in two different phases, and I think my choices
are still valid: one time I had to "introduce quality"
(tests) to an existing codebase (I took ownership, but
still could not afford massive refactorings) and another
time I had the luxory of writing complete modules. Same
project, mind you.
3) @Chad - I'm a big fan of refactoring and improving
and "winning the meeting" at design sessions, but that
aside - do you really think that "taking the time to
refactor" is ALWAYS possible?