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.
>
> > > > > 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]
>
> ...
>
> 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
-~----------~----~----~----~------~----~------~--~---
