I personally don't see the error with the test below. I would ask if you are feeling pain with this type of test. If the answer is no, I would proceed until such a point that you do rather than adhering to a list of rules arbitrarily. There are a lot of "rules" around unit testing and many of them make sense to me because of how I've experienced not adhering to the rules. Likewise, there are many "rules" that I've broken and never felt pain from breaking...and those are the rules I worry least about and wonder if they should have ever been rules in the first place.
On Wed, Feb 10, 2010 at 1:55 PM, Kevinst <[email protected]> wrote: > Hello everyone, > > "the art of unit testing" taught me that a try/catch block in a unit > test is bad practice. > > So I am hoping someone can help me to find the right approach. > > Let's say I have a class "Container" and a class "Foo" whereas the > Container contains a foo class and multiple container classes can > contain the same foo instance. > > Container is defined as following: > class Container > { > private Foo foo; > bool closeFooOnClose; > > public Container(Foo foo) > { > this.foo = foo; > } > > public void Open() > { > if(foo.IsOpenedExclusively) > { > throw new Exception(); > } > foo.OpenExclusively(); > closeFooOnClose = true; > } > > public void Close() > { > if(closeFooOnClose) > foo.Close(); > } > } > > > Foo: > > class Foo > { > public bool IsOpenedExclusively(); > public void OpenExclusively(){}; > public void Close(){}; > } > > > Now I want to test that Container will not try to close the Foo > instance in case the Open scenario failed. > So what comes to my mind first is: > > [TestMethod] > public void Close_FailedToOpenFoo_DoesNotTryToClose() > { > var foo = MockRepository.GenerateStrictMock<Foo>(); > foo.Expect(f => f.IsOpenedExclusively).Return(true); > > var uut = new Container(foo); > try { uut.Open(); } > catch(Exception { } > > uut.Close(); > > foo.VerifyAllExpectations(); > } > > > But.. as explained earlier I think try/catch blocks are to be avoided. > Maybe this is an exception? Or is there a way offered by rhino mocks > to deal with those scenarios? > Or do you know a way to refactor this to make it testable? > > Thank you, > Kevin > > -- > 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]<rhinomocks%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/rhinomocks?hl=en. > > -- Tim Barcz Microsoft C# MVP Microsoft ASPInsider http://timbarcz.devlicio.us http://www.twitter.com/timbarcz -- 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.
