ISerializable - Roy Osherove's Blog

I have long since changed my tune.  First let me say that I have always thought that TypeMock was a good idea for me to have I was just worried about the heathens using it. ;-)  Jeremy Miller convinced me that attitude was a problem and I now think that it is best to have the "sharpest tools" for all.

P.S. I don't like TypeMock being analogized to Scrum.  I fail to see how that takes you to a good place.

Lots of big claims Roy, but not much in the way of facts or examples.  Can we take the conversation off another way?  I, and a whole bunch of others, feel like the whole "I can mock anything, anytime, anywhere" thing is either harmful or not really that important in the greater scheme of things (my stance btw).  You might be walking uphill trying to argue the Type interception aspect of TypeMock as a deciding factor.  

That being said, what other reasons might I choose TypeMock over RhinoMocks?  RhinoMocks is free, and there's a huge amount of literature, community, and blogging examples of its usage.  I've seriously never seen an example of TypeMock usage on a blog.  Not one single blog post.

Personally, the only thing that's going to sell me on TypeMock over (FOSS) RhinoMocks is if you can show me that the syntax is easier to read and write.

I'm not really trying to argue with you so much as see exactly why you think TypeMock has an advantage over RhinoMocks.  Sell me on the usability of TypeMock.

@Jeremy

You are right, the free version of TypeMock does not have the same quality of syntax as Rhino. The versions you pay for have cool features but the price per desk seems to me to be prohibitive for a mocking framework.

Your blogs are just becoming a glorified advert for Typemocks.

If you are turning this into a us vs Rhino then remember that Rhino mocks beats you on the 2 major factors  - it comes at an attractive price and has great community support.

Jeremy, I blogged one example of using it ... which wasn't good, and Eli corrected it to a much better syntax (blog.goinsane.co.uk/CommentView,guid,090dc64c-396c-4d68-8741-853b4c0ceb52.aspx)  ... functionaly in my case it was roughly the same as Rhino Mocks, but had the advantage of being able to mock SharePoint in my case.

I mentioned the excellent community support for Rhino, and certainly convincing a client to shell out for TYpeMock on every desk would be an uphill struggle if they haven't already started pushing beyond the capabilities of Rhino Mocks ...

So I would certainly be interested in knowing the things it brings me beyond the other options in the market, mocking the unmockable is a big benefit for certain legacy systems ... but what else does it bring me the rest of the time?

I'm hoping that Roy going to TypeMock will bring some of his excellent testing examples to the TypeMock world, and increase visibility beyond the sales pitch on the site.

I do hope that Roy represents the new voice of TypeMock, this is a more reasonable position than we've seen in the past; TypeMock has been as dogmatic as any of us in this storm in a teacup. As I've said to Roy elsewhere, my issue (in case anyone cares) is not the tool but the position the authors have historically taken.

Personally, I'd like to feel that the people at TypeMock understand the trade-offs in their position, and that they're doing their bit to lead people on to the "good stuff". TypeMock has powerful features that can make a team more Agile--or help them paint themselves into a corner and give up in disgust.

I've been on a couple of gigs where I had to clean up complicated, brittle tests that were just dragging the team down. One of the worst problems was endless multi-level mocking to get around the fact that they weren't breaking up the code. The ability to override classes meant that they hadn't been thinking about object roles and responsibilities, just slicing through the code to get through this ****ing test. Often they'd have been better off writing integration tests instead. (I've also seen  some pretty unproductive Scrum adoptions too, so maybe the metaphor applies after all :-)

Pingback from  Video: Typemock Basics - Lesson 1 (Dependency breaking 101) - ISerializable - Roy Osherove's Blog

@Casey

"mocking the unmockable is a big benefit for certain legacy systems"

True but equally mocking something when I feel the current design is more than adequate is also a case.

at the beginning - during my evaluation of typemock - i was excited about the same things. i was sure that this tool finally teaches lazy coders to write unit tests. but i dont think that way anymore. you have to explain to people why unit testing matters and be sure they understood. there is no way to avoid unit testing consciously once you know what you are  getting.  typemock is nice but its definitelly not worth its price comparing with alternatives. i would buy it for 50 bucks because of few of its nifty features but not for the price that it is offered now. sorry

Ok, lets see if I can get in a groove for a few days Agile/Software Development When James Shore worked

[This post is in response to a post (actually a couple posts) that Roy Osherove has recently posted on

Pingback from  Eli Lopian’s Blog (TypeMock)  » Blog Archive   » Typemock and Design Issues

Ok, lets see if I can get in a groove for a few days Agile/Software Development When James Shore worked with my Agile team , he heavily used the concept of Etudes to improve technical skills . It worked extremely well in helping our team learn about our