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.
