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+InvocationCreateEntity_14[TEntity]'
violates the constraint of type parameter 'TEntity'. Stack Trace: at
IDbGatewayFactoryProxye92159cbc301435c98f90d81faefe3c7.CreateEntity<StronglyTypedValue>()
//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_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
>
> ...
>
> 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
-~----------~----~----~----~------~----~------~--~---
