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)
> > > > {
> > > > 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
-~----------~----~----~----~------~----~------~--~---
