Finally found the answer.
here
http://groups.google.com/group/castle-project-devel/browse_thread/thread/2ab9c89ef08a710f/373037a8293c5069
and here
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=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>()).Return(mo
> > > > ckUser);
> > > > }
>
> > > > //Type: System.TypeLoadException Message: GenericArguments[0],
> > > > 'StronglyTypedValue', on
> > > > 'IDbGatewayFactoryProxye92159cbc301435c98f90d81faefe3c7+InvocationCr
> > > > eateEnti
> > > > 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.
>
> ...
>
> 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
-~----------~----~----~----~------~----~------~--~---
