"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_present
> > > _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_from_
> > > 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 System.Reflection.RuntimeMethodInfo.GetParameters()
> > > at System.Diagnostics.StackTrace.ToString(TraceFormat
> > > traceFormat)
> > > at System.Environment.GetStackTrace(Exception e, Boolean
> > > needFileInfo)
> > > at System.Exception.get_StackTrace()
> > > at
> > > MbUnit.Core.Reports.Serialization.ReportException.FromException(Exce
> > > pt
> > > ion
> > > ex)
> > > at MbUnit.Core.Reports.Serialization.ReportRun.Failure(RunPipe
> > > pipe, ReportMo
> > > nitor monitor, Exception ex)
> > > at MbUnit.Core.RunPipeStarter.Run(Object fixture, Boolean
> > > IsExplicit)
> > > at
> > > MbUnit.Core.Remoting.FixtureRunnerBase.InternalRunFixture(Fixture
> > > fixture)
>
> > > at
> > > MbUnit.Core.Remoting.FixtureRunnerBase.FixtureRunnerStarter.Start()
>
> > > [cleaning] unloading domain
> > > [cleaning] domain unloaded
>
> > > On Jan 17, 11:18 am, "[EMAIL PROTECTED]"
> > > <[EMAIL PROTECTED]>
> > > wrote:
> > > > I have been experiencing this problem on and off for about a week.
> > > > I'm using v2.41.232.0. The problem does not occur if I test via
> > > > the
> > GUI.
>
> > > > The problem occurs with this code
> > > > using System;
> > > > using MbUnit.Core;
>
> > > > namespace ReportingFramework.Tests {
> > > > internal class Program
> > > > {
> > > > private static void Main()
> > > > {
> > > > using (AutoRunner runner = new AutoRunner())
> > > > {
> > > > runner.Run();
> > > > if (!runner.IsSuccess) runner.ReportToText();
> > > > }
> > > > Console.ReadKey();
> > > > }
> > > > }
>
> > > > }
>
> > > > here is the console output:
> > > > ------------------------------------------------------------------
> > > > --
> > > > --
> > > > ---------------------------------------
> > > > [error] Unexpected exception occured in MbUnit Internal error
> > > > while running tests in ReportingFramework.Tests
> > > > MbUnit.Core.Exceptions.FixtureExecutionException
> > > > Message: ConfigureReportTaskTest
> > > > 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 System.Reflection.RuntimeMethodInfo.GetParameters()
> > > > at System.Diagnostics.StackTrace.ToString(TraceFormat
> > > > traceFormat)
> > > > at System.Environment.GetStackTrace(Exception e, Boolean
> > > > needFileInfo)
> > > > at System.Exception.get_StackTrace()
> > > > at
> > > > MbUnit.Core.Reports.Serialization.ReportException.FromException(Ex
> > > > ce
> > > > pt
> > > > ion
> > > > ex)
> > > > at MbUnit.Core.Reports.Serialization.ReportRun.Failure(RunPipe
> > > > pipe, ReportMo
> > > > nitor monitor, Exception ex)
> > > > at MbUnit.Core.RunPipeStarter.Run(Object fixture, Boolean
> > > > IsExplicit)
> > > > at
> > > > MbUnit.Core.Remoting.FixtureRunnerBase.InternalRunFixture(Fixture
> > > > fixture)
>
> > > > at
> > > > MbUnit.Core.Remoting.FixtureRunnerBase.FixtureRunnerStarter.Start(
> > > > )
>
> > > > [cleaning] unloading domain
> > > > [cleaning] domain unloaded
>
> > > > After reviewing the stack trace above it appears mbunit is mixing
> > > > up generic calls. 'TypeOfItem' is never referenced in the
> > > > ORMSupportClass (LLBL 3rd party). I do have a generic object using
> > > > 'TypeOfItem' but that doesn't have anything to do with ORMSupportClass.
>
> > > > It also doesn't make sense that the error only occurs with
> > > > autorunner and not the GUI. I'm new to unit testing and rhino
> > > > mocks so I could be missing something, but this is very confusing.
> > > > Any help is very appreciated.
>
> > > > Thank you, Jason- Hide quoted text -
>
> > > - Show quoted text -- 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
-~----------~----~----~----~------~----~------~--~---
