This is what I use. I'm afraid it's not a PDF. http://ayende.com/wiki/Rhino%20Mocks%203.5.ashx
Iain On 20 October 2011 17:57, Laksh <[email protected]> wrote: > also i would i like to know is there any documenation with example on > how to use Rhino Mocks using version 3.6.0.0 > i'm following this PDF > http://ayende.com/wiki/GetFile.aspx?File=Rhino+Mocks+3.3+Quick+Reference.pdf > but its using 3.3 version > > On Oct 13, 5:22 pm, bill richards <[email protected]> > wrote: > > Further to Patrick's response .... > > > > So, it sounds to me like you have been asked to put some "unit tests" > > around a bunch of code that has been written; or you've written some > > code and thought 'right, this needs testing'. > > > > My advice would be to take a look at what it is you are trying to > > achieve, and what it is that you want to test. I would say that this > > "problem" has been tackled wrongly. By working in this manner, what > > you will find is that your "unit tests" are only testing your > > implementation, i.e. > > > > public class MyClass { public string MyName { get;set;} } > > public void NamePropertyTest() > > { > > // Arrange > > var myClass = new MyClass(); > > const string expectedName = "Bill"; > > > > // Act > > myClass.MyName = expectedName; > > > > // Assert > > Assert.AreEqual(expectedName, myClass.MyName, "NameProperty does not > > return expected name"); > > > > } > > > > What exactly is this test doing? ... it's pretty much testing the .Net > > framework's implementation of a Property getter/setter -which we know > > MUST work, otherwise the framework would be pretty shoddy and nobody's > > code would work. So, this is pretty much a useless test (unless of > > course you are working on the .net framework, in which case, I would > > say that this should definitely be one of the tests around Property > > syntax and usage!) > > > > Let's imagine however that this test is one of your "unit tests" and > > is run regularly as part of your test suite. All is fine and dandy and > > you're thinking that you've done a great job because you've got > > yourself 100% code coverage when you run nCover or whatever, and your > > test always passes. > > > > Later on in response to a user request something changes about the > > implementation of MyName ... for example, it might check that a > > surname is present and return a concatenated "full name" instead of > > the thing that you set, for example: > > > > private string _myName; > > private string _familyName; > > public string MyName > > { > > set > > { > > _myName = string.IsNullOrEmpty(_familyName) > > ? value > > : string.Format("{0} {1}", value, > > _familyName); > > } > > get { return _myName; } > > > > } > > > > Forget for the time being that this functionality is completely whacky > > and is in itself WRONG WRONG WRONG, and imagine that it is a real > > requirement; so you've coded it all up and you've run your test and > > all is well that ends well, but when you run your entire test suite > > you get the assertion failed message : "NameProperty does not return > > expected name". This happens because some other test perhaps the test > > for FamilyName { get;set; } has set a family name, and now MyName > > actually returns "Bill Richards" and not "Bill" > > > > So what do you do to get your test to pass? Well, you could *hack* it > > and make sure you setup and teardown your MyClass before each test > > (although I say *hack* here, you really ought to do this and it is not > > really a hack, even though it is for this example!), or you could > > write into your test some fancy footwork to get hold of the FamilyName > > if it has already been set and check that the returned value from > > MyName is equal to Bill FamilyName. But you will most likely fiind > > that out in the "real world" qwhen the application is deployed you > > will get some *unexpected behaviour* something which you cannot > > reproduce in your test environment. > > > > This is because you have tailored your test to the implementation of > > your class, instead of testing the behaviour of your class ... > > > > Lots more to write on this subject, but it's time for bed and I think > > that maybe I'm rambling a bit, and maybe even I've gone a little "off > > topic"; but in a nutshell what I think I'm trying to say is ... > > > > Write your Test first, then write your code to pass your test, and you > > will find that you are testing the behaviour/requirement rather than > > the impementation. > > -- > You received this message because you are subscribed to the Google Groups > "Rhino.Mocks" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rhinomocks?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Rhino.Mocks" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rhinomocks?hl=en.
