here is the link to the sample code on Rhino.Mocks group. http://groups.google.com/group/RhinoMocks/browse_thread/thread/b065016a489fda15/63566ca2633431ae#63566ca2633431ae
On Jan 21, 10:50 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > I can't explain why but here are my results with testing frameworks, > rhino.mocks and generics: > > MbUnit AutoRunner fails by "mixing up" generics > MbUnit GUI passes all tests > MbUnit Con doesn't find the test fixtures using the follow command > line: > C:\program files\MbUnit>MbUnit.Cons > /ap:"c:\JMeckley\My Documents\Visual Studio 2005\Projects > \RhinoMocskGenericTest\MbUnitConsoleTest\MbUnitConsoleTest.csproj" > /rt:text > /rf:"c:\JMeckley\My Documents\Visual Studio 2005\Projects > \RhinoMocskGenericTest\MbUnitConsoleTest" /rnf:results > uNnit GUI passes all tests > nUnit Con passes all tests > > On Jan 21, 9:44 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > wrote: > > > > > 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 > > athttp://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) > > > > > { > > ... > > 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 -~----------~----~----~----~------~----~------~--~---
