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