Thanks you guys ... and you are right the buch of code is already written and we are using Rhino for unit testing. The module i'm working involes lot of System.IO.Stream classes. I never used Rhino before. The "Document" class i mentioned above is actually a wrppaer around Stream class....i wrote few Unit test using Rhino but as you mentioned i personally felt like they are "useless"..meaning they are not testing what i wanted to test.. Since the Stream class is involved in each class, there is external dependany there. So i have integration test that tests from start to end...but i was not sure how do i use Rhino for Unit testing
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.
