I gave Pex a shot a while back and it did some v. odd things, seemed
inclined to change the SUT with Pex specific magic when I told it to
resolve errors. Definitely want to give it another shot though, but
not what I'd expected.

--- In glasgow_altdotnet_usersgroup@yahoogroups.com, "dsmyth2001"
<derek.smyth@...> wrote:
>
> OK so yous didn't mock me (pun intended) for posting that so I must
> have understood what I have been reading. Stubs did seem easier to
> apply but an understanding of mocks wouldn't hurt. Thanks for
> replying, I'll take your advice on board.
>
> Actually, just for interest, came across something called Pex. It's
> an MS thing but basically it autogenerates your unit tests for you
> through paramaters and I quote....
>
> "...adding parameters (to unit tests) we turn a closed unit test into
> a universally quantified conditional axiom."
>
> In English that means if you have three branches in a method then you
> write one unit test and Pex works out the values necessary to visit
> each branch. What I read suggested it should be used along side
> regular test frameworks.
>
> http://research.microsoft.com/projects/pex/
>
> There is an article here if your wanting to know more...
> http://research.microsoft.com/projects/pex/articles/pextutorial.pdf
>
> I don't know, just sharing the research.
>
>
>
> --- In glasgow_altdotnet_usersgroup@yahoogroups.com, "Chris Canal"
> <dhtmlgod@> wrote:
> >
> > I don't use any mocks anymore, instead I use stubs. In the tests
> that are
> > concerned with the interaction between the dependency and
> method/system
> > under test I will try and assert on the return. If this isn't
> possible, say
> > for a Save/UPdate call, I will then use the AssertWasCalled
> extension
> > method.
> >
> > I would use a Stub over a Mock in every given situation. So far
> anyway. I
> > have been down the road of using Strict Mocks, and it was a very
> painful
> > experience.
> >
> > On Mon, Oct 20, 2008 at 8:51 PM, Paul Cowan <dagda1@> wrote:
> >
> > > I only really have experience of Rhino.Mocks.
> > >
> > > One of the problems of mocking is we have so many names for
> similar things.
> > >
> > > Since the advent of Rhino.Mocks 3.5 and indeed the AAA syntax
> over the
> > > record and playback model, I very rarely if ever use mocks.
> > >
> > > I would want to use mocks if I want to test that a mocked method
> is called.
> > >
> > > I use Stubs to control the input and output of data into the
> system under
> > > test.
> > >
> > > You can confusingly assert that stubs were called.
> > >
> > > IMO mocks lead to more brittle tests.
> > >
> > > This might help to clear it up.
> > >
> > > http://ayende.com/wiki/Rhino%20Mocks%20-%20Stubs.ashx
> > >
> > > Paul
> > >
> > > dagda1@
> > >
> > >
> > > ------------------------------
> > >
> > > To: glasgow_altdotnet_usersgroup@yahoogroups.com
> > > From: derek.smyth@
> > > Date: Mon, 20 Oct 2008 19:41:53 +0000
> > > Subject: [glasgow_altdotnet_usersgroup] TDD, Mocks, Stubs, IoC,
> DI, getting
> > > it straight.
> > >
> > >
> > > Hi folks,
> > >
> > > May I ask, have I got this right....
> > >
> > > TDD is based on writing tests before you write your code. The test
> > > initially fails and then the code is written to pass the tests.
> > >
> > > The code written might have dependencies to resources (external to
> > > the application) and dependencies to other classes that haven't
> been
> > > written yet.
> > >
> > > To get around that for testing purposes mocks and stubs are
> created.
> > > Dependency injection is used to 'fill in the gaps' for the test
> cases
> > > for the missing dependencies of the class thats being tested.
> > >
> > > Doing it that way means when the proper 'dependent' classes are
> > > developed you can add them in to the application very easily
> without
> > > effecting the test cases.
> > >
> > > Stubs are used in place of classes that haven't been developed yet
> > > and which access external resources. They are normally used to
> > > validate state. IsNameValid, etc...
> > >
> > > While Mocks are used to test behaviour of the class to ensure it
> > > calls the correct methods of the 'soon to be developed' class
> > > dependencies (of the class being tested).
> > >
> > > *phew*
> > >
> > > I'm still not completely sure of when you would create a stub and
> > > when you would create a mock? Or whether it matters if you decide
> to
> > > develop one over the other. I read that mocks are behaviour based
> and
> > > stubs are state based, is that correct? Doesn't correct state
> imply
> > > correct behaviour? and vice versa. Would you need to test for
> both,
> > > is it just safer to do so?
> > >
> > > It's all theory at the moment and it's theory pulled from a
> number of
> > > sources. If anyone could tell me if I'm on the right track then
> I'd
> > > appreciate it.
> > >
> > >
> > >
> > > ------------------------------
> > > Read amazing stories to your kids on Messenger Try it Now!
> <http://clk.atdmt.com/GBL/go/115454060/direct/01/>
> > >
> > >
> >
> >
> >
> > --
> > "Any fool can write code that a computer can understand. Good
> programmers
> > write code that humans can understand."
> > -Martin Fowler et al, Refactoring: Improving the Design of Existing
> Code
> >
>