I was able to recreate the failing test in a simple example using MbUnit 2.4 and Rhino.Mocks 3.3. It's in the process of submission at http://groups.google.com/group/RhinoMocks. Once it offically posts, I'll add the direct link here.
The new tests are not crashing MbUnit. instead they are failing the because the (bogus) generic constraints are not met. I believe if the tests run 2, 1 (intstead of 1, 2) MbUnit would crash. I'm going to try the same test with nUnit as well. Shouldn't make a difference, but just in case. On Jan 18, 1:10 pm, "Jeff Brown" <[EMAIL PROTECTED]> wrote: > This behavior is automatically provided for you by the framework. > > Throwing an exception from a test is what causes the test to fail. > > Jeff. > > > > -----Original Message----- > From: [email protected] [mailto:[EMAIL PROTECTED] On > > Behalf Of [EMAIL PROTECTED] > Sent: Friday, January 18, 2008 7:10 AM > To: MbUnit.User > Subject: MbUnit Re: Fatal Crash, not sure why > > Ok, I created another attribute to fail assertions if an exception is > caught. I modeled it on my other RunInRealContainer attribute. (BTW, > attributes are very slick). This was much easier than adding try/catch to > multiple tests. > namespace ReportingFramework.Tests > { > public class FatalExceptionNet : DecoratorPatternAttribute > { > public override IRunInvoker GetInvoker(IRunInvoker wrapper) > { > return new FatalExceptionNetRunInvoker(wrapper); > } > > private class FatalExceptionNetRunInvoker : > DecoratorRunInvoker > { > public FatalExceptionNetRunInvoker(IRunInvoker invoker) > : base(invoker) > { > } > > public override object Execute(object o, IList args) > { > object result = null; > try > { > result = Invoker.Execute(o, args); > } > catch(Exception exception) > { > StringBuilder builder = new StringBuilder(); > BuildFailMessage(exception, builder); > Assert.Fail(builder.ToString()); > } > return result; > } > > private void BuildFailMessage(Exception exception, StringBuilder > builder) > { > if (exception == null) return; > > builder.AppendLine("Caught exception:"); > builder.AppendFormat("{0}Type: {1}", "\t", > exception.GetType().FullName); > builder.AppendLine(); > builder.AppendFormat("{0}Message: {1}", "\t", > exception.Message); > builder.AppendLine(); > builder.AppendFormat("{0}Stack Trace: {1}", "\t", > exception.StackTrace); > builder.AppendLine(); > > BuildFailMessage(exception.InnerException, builder); > } > } > } > } > > I also implmented the try/finally suggestion for my RunInRealContainer > attribute. I applied the above attribute to any test that references > IDbGatewayFactory. I ran the test twice. the 1s time every passed > successfully. the 2nd time I received 21 failures. 19 related to the > generics issue. the stack trace points to cross contamination between > generics. these are examples of failure points: > ---------------------------------------------------------------------------- > -------------------------- > public interface IItemFactory > { > IBaggedItem Create<TypeOfValue>(TypeOfValue value); } > > IItemFactory mockFactory = mockery.DynamicMock<IItemFactory>(); > IBaggedItem mockBaggedItem = mockery.DynamicMock<IBaggedItem>(); > Expect.Call(mockFactory.Create("foo")).Return(mockBaggedItem); > > // message: Method > IItemFactoryProxy372b9a768dc64f1fb018f60bfb01a828.Create: type argument > 'System.String' violates the constraint of type parameter 'TEntity' > // this generic method does not have a where clause > ---------------------------------------------------------------------------- > -------------------------- > public interface IDbGatewayFactory > { > EntityCollection<TEntity> CreateEntityCollection<TEntity>() where TEntity > : EntityBase2, IEntity2; > TEntity CreateEntity<TEntity>() where TEntity : EntityBase2, IEntity2, > new(); } > > using (mockery.Record()) > { > IDbGatewayFactory mockGatewayFactory = > mockery.DynamicMock<IDbGatewayFactory>(); > UserEntity mockUser = mockery.DynamicMock<UserEntity>(); > > Expect.Call(mockGatewayFactory.CreateEntity<UserEntity>()).Return(mockUser); > } > > //Type: System.TypeLoadException Message: GenericArguments[0], > 'StronglyTypedValue', on > 'IDbGatewayFactoryProxye92159cbc301435c98f90d81faefe3c7+InvocationCreateEnti > ty_14[TEntity]' > violates the constraint of type parameter 'TEntity'. Stack Trace: at > IDbGatewayFactoryProxye92159cbc301435c98f90d81faefe3c7.CreateEntity<Strongly > TypedValue>() > //StronglyTypedValue does not appear in any of my code relating to > IDbGatewayFactory. > > So this seems to relate back to a Rhino.Mocks issue. I know generics are > getting mixed, but how do I explain this with some level of detail for Oren. > I feel like I'm still at a point to say it's broken, but I don't know why. > > On Jan 18, 8:27 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > wrote: > > "shouldn't your DependencyResolver.InitializeWith(null) line go in a > > finally block? Otherwise it won't run after a test failure." > > Honestly I don't know... I picked up this technique from a training > > seminar. This may explain why my computer seems to slow down durning > > the day. From test to test it shouldn't matter because > > ApplicationStart.Run() overwrites the original implmentation. > > > That said, i will apply the finally block to see if this helps with > > preformance. I could also include a > > DependencyResolver.InitializeWith(null) after the using autorunner > > block as well, but i don't think this would adhere to strick unit > > testing principles. > > > I'll refactor the unit test's which mock IDbGatewayFactory and post > > back the results. > > > Gallio, what's that? > > > On Jan 17, 7:38 pm, Jeff Brown <[EMAIL PROTECTED]> wrote: > > > > BTW, shouldn't your DependencyResolver.InitializeWith(null) line go in a > finally block? Otherwise it won't run after a test failure. > > > > So Rhino.Mocks is in play. Hmm. I take it your test contains a mock of > IDbGatewayFactoryProxy. > > > > As I said before, what's happening is that the test is failing within > the Dynamic Proxy code itself. That is to say, Rhino.Mocks is generating > bad code. > > > > MbUnit is then unable to capture the stack trace from the Exception. > This is a very unusual condition. But now having observed it, I think I'll > add some code to Gallio so that it can protect itself against unprintable > exceptions. > > > > So to understand the problem better, I'd like you to instrument your > test as follows: > > > > [Test] > > > public void Test() > > > { > > > try > > > { > > > // your actual test code. > > > } > > > catch (Exception ex) > > > { > > > Assert.Fail("Caught an exception of type {0} and message > > > {1}.", ex.GetType().FullName, ex.Message); > > > } > > > > } > > > > The other thing I'd like to add, is that if it turns out Rhino.Mocks is > generating bad code in some situations then we should ask Oren to take a > look at it. It may be a known bug. > > > > Jeff.-----Original Message----- > > > From: [email protected] > > > [mailto:[EMAIL PROTECTED] On Behalf Of > > > [EMAIL PROTECTED] > > > Sent: Thursday, January 17, 2008 1:39 PM > > > To: MbUnit.User > > > Subject: MbUnit Re: Fatal Crash, not sure why > > > > I use RowTest for some of the repository tests. I also use Rollback > whenever I save/delete from the db for a test. > > > I also created a RunInRealContainer attribute, which is like a startup > script which runs before each test. after completing the test it destroys > all the objects. > > > > namespace ReportingFramework.Tests > > > { > > > public class RunInRealContainer : DecoratorPatternAttribute > > > { > > > public override IRunInvoker GetInvoker(IRunInvoker wrapper) > > > { > > > return new RunInRealContainerRunInvoker(wrapper); > > > } > > > > private class RunInRealContainerRunInvoker : > > > DecoratorRunInvoker > > > { > > > public RunInRealContainerRunInvoker(IRunInvoker invoker) > > > : base(invoker) > > > { > > > } > > > > public override object Execute(object o, IList args) > > > { > > > ApplicationStartupCommand.Run(); > > > object result = Invoker.Execute(o, args); > > > DependencyResolver.InitializeWith(null); > > > return result; > > > } > > > } > > > } > > > } > > > > ApplicationStartupCommand.Run(); is like poor mans dependency injection > which loads the dependency resolver with all the types i need for > constructors. after the test runs DependencyResolver destroys the objects > with the null argument. I only use this attribute when running integration > tests, not unit tests. reviewing where my code is breaking none of these > attributes seem to apply. > > > > Tests seem to execute in a completely random order (hashtable?) so I can > say where it actually breaks. i do know the generic type exceptions are > thrown in the repository unit tests using rhino.mock 3.3. It do not appear > to error in integration tests. > > > > I applied the ApartmentState value to the test fixtures I believed to be > the problem. this did not change the results. mbunit still fatally crashed. > > > > Jason > > > > On Jan 17, 3:30 pm, "Jeff Brown" <[EMAIL PROTECTED]> wrote: > > > > I can't think of anything MbUnit might try to do with the dynamic > > > > proxy type. It probably doesn't know it exists. Are you using > > > > TypeFixture or factories or other advanced MbUnit features in your > tests? > > > > > However since you mention it works in the GUI. Try setting the > > > > ApartmentState property on your test fixture, like this: > > > > > [TestFixture(ApartmentState=ApartmentState.STA)] > > > > > Jeff. > > > > > -----Original Message----- > > > > From: [email protected] > > > > [mailto:[EMAIL PROTECTED] > > > > On > > > > > Behalf Of [EMAIL PROTECTED] > > > > Sent: Thursday, January 17, 2008 12:11 PM > > > > To: MbUnit.User > > > > Subject: MbUnit Re: Fatal Crash, not sure why > > > > > the strange thing is sometimes (i hate that word in programming:) > > > > ) all the test run successfully, other times they run and some > > ... > > read more »- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MbUnit.User" 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/MbUnitUser?hl=en -~----------~----~----~----~------~----~------~--~---
