ISerializable - Roy Osherove's Blog

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.

@Roy:  I'm very disappointed in this hit piece and it's totally uncalled for.

I've said it before, and I'll say it again, TDD is not about tests, it's about design and TypeMock is all about keeping your existing coupled design and using magic to be able to test it.

Like Casey said, I do not consider perpetuating an otherwise unmaintainable design as 'WORKS', therefore TypeMock only further delays the inevitable and ultimately compounds the pain for a later date.

Granted, if that's what you're currently stuck with and you're trying to shovel your way out of a poorly designed legacy code problem, TypeMock is great for getting the ball rolling towards an ultimate goal of decoupled design and has a lasting, maintainable legacy.

But using TypeMock as your primary mode of enabling your coupled/opaque design is a recipe for long-term disaster.

So if you want to call people like me 'dogmatic' for asserting 'Sky is blue, water is wet, decoupled design is the only design which will result in long-term success', then so be it, but it's rather inflammatory and akin to pushing people in front of the bus.

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.

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.

I respect you opinions Roy. You know how big of a man-crush I have on you, right?

Actually, I agree with you about the common approach Alt.NET to DI, IoC, and interface-based development. I believe there is not just room, but a need for some innovation there. I also believe deep inheritance hierarchies are a real problem, I am on the record about favoring Polymorphism through Composition over Inheritance.

That said, I still consider myself part of Alt.NET and I don't like to be called dogmatic. Especially when my views are the minority (at the moment).

And lastly, I really appreciate Typmock's sponsorship of the Alt.NET Podcast. One of our goals there is to promote understanding and dispel FUD. Perhaps we should have you and Daniel on a episode to discuss this?

http://altnetpodcast.com/

@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.

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.

In continuation to my last post about duplicity in the ALT.NET community and around, Eli has a nice post

Pingback from  Eli Lopian&#8217;s Blog (TypeMock)  &raquo; Blog Archive   &raquo; Mocking frameworks - dream feature

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.

My latest post about "creating wrapper classes" for mocking the WCF context has started generating some

>>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.

Roy makes a number of accusations about the Alt.net community, particularly centred around their espoused

@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 disagree with Roy's statement that Daniel is being hypocritical by ending on the agile mantra "Always use the simplest thing that could possibly work." Simple does not equal easy: if it were easy to replicate the simplicity of the iPod, we would all be carrying Zunes. Yes, TypeMock allows you to easily isolate existing code so you can more accurately target the code under test. But, firstly, there is nothing simple about the under the cover magic TypeMock uses to mock statics, intercept method calls, or whatever. In the past, I have had my code and other tools (like JetBrains' DotTrace) fail simply because TypeMock was installed, even though I wasn't using it! Those issues have been fixed, but what if a new tool comes out that falls victim to the same problem? Secondly, allowing new code to make the easiest choices, such as using a static method for business logic, can have complicated, long term effects that TypeMock may hide during testing or even encourage because of its ease of use.

While TypeMock is both easy to use and powerful, I contend it is not "the simplest thing that could possibly work." In many cases, designing for testability  can be a more simple choice.

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?