Associating abstract classes/interfaces with their Concrete Impls (WAS: Does adding a From Property to AutoFixture.xUnit' FrozenAttribute make sense)

Sep 19, 2012 at 12:08 PM
Edited Sep 19, 2012 at 12:55 PM

I currently am using a fork of FrozenAttribute:- 

[AttributeUsage( AttributeTargets.Parameter, AllowMultiple = false )]
public sealed class FrozenAttribute2 : CustomizeAttribute
{
	public override ICustomization GetCustomization( ParameterInfo parameter )
	{
		if ( parameter == null )
			throw new ArgumentNullException( "parameter" );
		Type parameterType = parameter.ParameterType;
		return new FreezingCustomization( this.From ?? parameterType, this.As ?? parameterType );
} public Type As { get; set; } public Type From { get; set; } }

This allows me to collapse:

void Test(
  ConcreteSut sut_)
{
    var sut = (IRealInterfaceToSut)sut_;
	// body
}

To:

void Test( [Frozen2(From=typeof(ConcreteSut))] IRealInterfaceToSut sut) { // body }

The freezing aspect isnt useful in this case, but the reason I got here is that I see it as being more or less the dual of As on [Frozen].

a) Is there anything similar that I should use instead which I've just missed?

b) Should I log an Issue to add a From property to FrozenAttribute?

c) Should I log an Issue to add DownCastedAttribute which would directly do my actual requirement only?

I'm hoping it's a)

@codeplex: This HTML editor is nearly as bad as our corporate CMS. And that's saying a lot.

Coordinator
Sep 21, 2012 at 11:36 AM

If you don't particularly need the [Frozen] attribute, why not do this?

void Test(ConcreteSut c)
{
    IRealInterfaceToSut sut = c;

    // ...
}

if you want a one-off solution.

For a more general solution, you could map IRealInterfaceToSut to ConcreteSut and just request that:

void Test(IRealInterfaceToSut sut)
{
    // ...
}

Sep 21, 2012 at 7:43 PM
Edited Sep 21, 2012 at 7:44 PM

Nice subtlety on the first one - I  think the longer I looked at it the less likely I'd have come up with that one (and I'm doing a lot of JS at the moment so as Nikos' recent tweet suggests I'm less likely consider legacy variable declaration styles :D). The key reason I'm looking to reduce the statement count by 1 [by getting the casting busywork out of the mainline code] is that the combination of being able to

a) put a concrete CustomizeAttribute onto a Test Method parameter

b) rely on preparing side effects by having a Test Method argument represent the Arrange step (either as a Context with some helpers or just as a Fixture which Arranges itself)

means I typically don't have an Arrange of which to speak.

The latter solution (that I also would never have arrived at) is actually perfect. I can put the Customize call into the AutoDataAttribute or a concrete CustomizeAttribute as suits (for some reason I was blind to the fact that for a given Test [nested sub]Class the core SUT Type mapping should be stable.

I really appreciate both ideas (and your yet-again-demonstrated invaluable instinct for elegant solutions!).