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 argument. I only use this attribute when running integration tests, not unit tests. reviewing where my code is breaking none of these attributes seem to apply. > > > Tests seem to execute in a completely random order (hashtable?) so I can say where it actually breaks. i do know the generic type exceptions are thrown in the repository unit tests using rhino.mock 3.3. It do not appear to error in integration tests. > > > I applied the ApartmentState value to the test fixtures I believed to be the problem. this did not change the results. mbunit still fatally crashed. > > > Jason > > > On Jan 17, 3:30 pm, "Jeff Brown" <[EMAIL PROTECTED]> wrote: > > > I can't think of anything MbUnit might try to do with the dynamic > > > proxy type. It probably doesn't know it exists. Are you using > > > TypeFixture or factories or other advanced MbUnit features in your tests? > > > > However since you mention it works in the GUI. Try setting the > > > ApartmentState property on your test fixture, like this: > > > > [TestFixture(ApartmentState=ApartmentState.STA)] > > > > Jeff. > > > > -----Original Message----- > > > From: [email protected] > > > [mailto:[EMAIL PROTECTED] > > > On > > > > Behalf Of [EMAIL PROTECTED] > > > Sent: Thursday, January 17, 2008 12:11 PM > > > To: MbUnit.User > > > Subject: MbUnit Re: Fatal Crash, not sure why > > > > the strange thing is sometimes (i hate that word in programming:) > > > ) all the test run successfully, other times they run and some > > > test using generics fails, but mbunit does not crash. Then still > > > other times it crashes like above. I believe it is crashing at 2 > > > or 3 specific tests. whichever one is reached 1/st2nd? then it > > > fails. it also doesn't fail if I run the gui (web > > > forms) or mbunit gui. I haven't tried mbunit.console yet. > > > > there is alot (probally too much) code to post to incorporate to > > > reproduce the problem. > > > > not knowing much about dynamic proxies/generics. could it be the > > > generic variable is cross referenced with another object. for example: > > > interface Foo<MyType> > > > { > > > } > > > > interface Bar<MyType> : where MyType ISomeOtherInterface, new() { > > > } > > > > mbunit is trying to pass the Foo MyType to the Bar MyType which can work? > > > This seems to be what the error message states. If that's the > > > case, would prefixing MyType (company name) fix the problem? > > > interface Foo<AcmeMyType> > > > { > > > } > > > > interface Bar<MyType> : where MyType ISomeOtherInterface, new() { > > > } > > > > Thank you, Jason > > > > On Jan 17, 1:33 pm, "Jeff Brown" <[EMAIL PROTECTED]> wrote: > > > > So this looks like a dynamic proxy type that is being created by > > > > LLBL itself while your test runs. I don't think MbUnit is doing > > > > anything directly to cause it. I would guess that LLBL is generating bad code. > > > > > It looks like the error is being detected while a stack trace > > > > for some other Exception is being produced. You'll notice the > > > > failure occurs in GetSignature while getting the stack trace of > > > > an Exception in order to report the original error. So the > > > > original Exception itself is being > > > lost. > > > > It probably occurred inside the malformed dynamic proxy class. > > > > > Could you attach the source to your UserRepositoryTest and any > > > > relevant objects? > > > > > You might also want to check on the LLBL mailing list. > > > > > Jeff. > > > > > -----Original Message----- > > > > From: [email protected] > > > > [mailto:[EMAIL PROTECTED] > > > > On > > > > > Behalf Of [EMAIL PROTECTED] > > > > Sent: Thursday, January 17, 2008 8:35 AM > > > > To: MbUnit.User > > > > Subject: MbUnit Re: Fatal Crash, not sure why > > > > > I just re-ran the tests twice to confirm the issue. the 1st > > > > re-run completed successfullly. the 2nd crashed again. Similiar > > > > issue with mis-matched generics, but at a different location. > > > > > [failure] > > > > UserRepositoryTest.Setup.Should_return_user_from_ldap_if_not_pre > > > > sent > > > > _i > > > > n_database: GenericArguments[0], 'TypeOfItem', on > > > > 'IDbGatewayFactoryProxy3a9aab2 > > > > b37e34599bd9e40543e372619+InvocationCreateEntity_14[TypeOfEntity]' > > > > violates the > > > > constraint of type parameter 'TypeOfEntity'. > > > > [failure] > > > > UserRepositoryTest.Setup.Should_be_able_to_fetch_a_user_entity_f > > > > rom_ > > > > th > > > > e_database: GenericArguments[0], 'TypeOfItem', on > > > > 'IDbGatewayFactoryProxy3a9aab2 > > > > b37e34599bd9e40543e372619+InvocationCreateEntity_14[TypeOfEntity]' > > > > violates the > > > > constraint of type parameter 'TypeOfEntity'. > > > > [success] > > > > UserRepositoryTest.Setup.Should_be_able_to_fetch_all_users > > > > [error] Unexpected exception occured in MbUnit Internal error > > > > while running tests in ReportingFramework.Tests > > > > MbUnit.Core.Exceptions.FixtureExecutionException > > > > Message: UserRepositoryTest > > > > Source: MbUnit.Framework > > > > StackTrace: > > > > at MbUnit.Core.Remoting.FixtureRunnerBase.RunFixture(Fixture > > > > fixture) > > > > at MbUnit.Core.Remoting.DependencyFixtureRunner.RunFixtures() > > > > at MbUnit.Core.Remoting.FixtureRunnerBase.Run(FixtureExplorer > > > > explorer, Repor > > > > tListener reportListener) > > > > Inner Exception > > > > System.TypeLoadException > > > > Message: GenericArguments[0], 'TypeOfItem', on > > > > 'SD.LLBLGen.Pro.ORMSupportClasses .CollectionCore`1[T]' violates > > > > the constraint of type parameter 'T'. > > > > Source: mscorlib > > > > StackTrace: > > > > at System.Signature._GetSignature(SignatureStruct& signature, > > > > Void* pCorSig, > > > > Int32 cCorSig, IntPtr fieldHandle, IntPtr methodHandle, IntPtr > > > > declaringTypeHand > > > > le) > > > > at System.Signature.GetSignature(SignatureStruct& signature, > > > > Void* pCorSig, I > > > > nt32 cCorSig, RuntimeFieldHandle fieldHandle, > > > > RuntimeMethodHandle methodHandle, RuntimeTypeHandle > > > > declaringTypeHandle) > > > > at System.Signature..ctor(RuntimeMethodHandle methodHandle, > > > > RuntimeTypeHandle > > > > declaringTypeHandle) > > > > at System.Reflection.RuntimeMethodInfo.get_Signature() > > > > at > > ... > > 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 -~----------~----~----~----~------~----~------~--~---
