Wow! Weird stuff... Jeff.
-----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, January 22, 2008 11:04 AM To: MbUnit.User Subject: MbUnit Re: Fatal Crash, not sure why Finally found the answer. here http://groups.google.com/group/castle-project-devel/browse_thread/thread/2ab 9c89ef08a710f/373037a8293c5069 and here http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedbac kID=262509 it's a problem with the debugger, dynamic proxies and constrained generics. That explains why it's only a problem with autorunner and not Con or GUI I guess this hasn't surfaced before because most development enviornments are either using the GUI or an automated build (CC.net TD.net)with the Console. Thank you for all your feedback in this matter. Jason On Jan 21, 8:01 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > I got mbunit console to run > C:\Program Files\MbUnit>MbUnit.Cons.exe "c:\JMeckley\My Documents > \Visual Studio 2005\Projects\RhinoMocskGenericTest\MbUnitConsoleTest > \bin\Debug\MbUnitConsoleTest.dll" /rt:text /rf:"c:\JMeckley\My > Documents\Visual Studio 2005\Projects\RhinoMocskGenericTest > \MbUnitConsoleTest" /rnf:results > everything ran successfully. > > out of sheer desperation I applied [STAThread] to the interal class > program.Main(). still no luck. > it does seem to be that it is dependent on when the test runs in > relation to the other test (assert 1, assert 2 or assert 2, assert 1). > Today I tested via the GUI just to avoid the TypeLoad exception. > > thank you for your continued support. > > On Jan 21, 1:42 pm, "Jeff Brown" <[EMAIL PROTECTED]> wrote: > > > > > I wonder if different versions of the libraries are getting loaded > > by different runners. > > > However the MbUnit.Cons command line below is incorrect. The /ap: > > argument should contain the path of the directory that contains the test assemblies. > > So the "bin" dir. It it also optional. > > > The command-line also requires at least one dll to be specified. So... > > > MbUnit.Cons "MyProject\bin\Debug\MyAssembly.dll" /ap:"MyProject\bin\Debug" > > {other arguments} > > > You may also get different results if you run MbUnit.Cons from > > within the directory that contains the assembly due to how assembly > > loading work in MbUnit v2. > > > Jeff. > > > -----Original Message----- > > From: [email protected] > > [mailto:[EMAIL PROTECTED] On > > > Behalf Of [EMAIL PROTECTED] > > Sent: Monday, January 21, 2008 7:50 AM > > To: MbUnit.User > > Subject: MbUnit Re: Fatal Crash, not sure why > > > 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>()).Retur > > > > n(mo > > > > ckUser); > > > > } > > > > > //Type: System.TypeLoadException Message: GenericArguments[0], > > > > 'StronglyTypedValue', on > > > > 'IDbGatewayFactoryProxye92159cbc301435c98f90d81faefe3c7+Invocati > > > > onCr > > > > eateEnti > > > > ty_14[TEntity]' > > > > violates the constraint of type parameter 'TEntity'. Stack > > > > Trace: at > > > > IDbGatewayFactoryProxye92159cbc301435c98f90d81faefe3c7.CreateEnt > > > > ity< > > > > 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. > > ... > > 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 -~----------~----~----~----~------~----~------~--~---
