Done

From: Mark Seemann [mailto:notifications@github.com]
Sent: Sonntag, 30. Dezember 2012 21:25
To: AutoFixture/AutoFixture
Cc: Daniel Hilgarth
Subject: Re: [AutoFixture] AutoNSubstitute (#54)


In Src/AutoNSubstitute/NSubstituteBuilder.cs:

> +        ///     <paramref name="builder"/> is subsequently available through the <see cref="Builder"/> property.

> +        /// </remarks>

> +        /// <seealso cref="Builder"/>

> +        public NSubstituteBuilder(ISpecimenBuilder builder)

> +            : this(builder, t => t != null && (t.IsInterface || t.IsAbstract))

> +        {

> +        }

> +

> +        /// <summary>Initializes a new instance of the <see cref="NSubstituteBuilder"/> class with an

> +        ///     <see cref="ISpecimenBuilder"/> to decorate.</summary>

> +        /// <param name="builder">The builder which must build mock instances.</param>

> +        /// <param name="substitutionSpecification">A specification that determines whether a substitute should be created for a given type or not.</param>

> +        /// <remarks>

> +        ///     <paramref name="builder"/> is subsequently available through the <see cref="Builder"/> property.

> +        /// </remarks>

> +        /// <seealso cref="Builder"/>

Consider, for a moment, NSubstituteBuilder as a black box. It implements ISpecimenBuilder where the only method has this signature:

object Create(object request, ISpecimenContext context)

There's a request coming in, and that's an object.

Now, via one of the constructor overloads, the class now informs the user that it accepts a Specification. Right now, that Specification is expressed in terms of Type. Don't you think that obscures the source of the Type instance?

Would it be fair to say that given that the class already implements ISpecimenBuilder, taking IRequestSpecification as a dependency more clearly communicates the collaboration between these two abstractions?

bool IsSatisfiedBy(object request)

Personally, I can almost visually see a line connecting those two request arguments.

________________________________

Here's another question: when the Specification is provided as a Func, how would you ever use the SubstitutionSpecification property for structural testing? Yes: it's possible to test that the injected Specification is equal to the property, but what if you wanted to test that the default Specification exhibits certain, desired behavior? What if, in the future, you have a third party that creates an instance of NSubstituteBuilder and you want to unit test that it created the instance with an appropriate Specification?

Testing like this is really difficult. For the record, I had to do a lot of testing like this when I implemented the 3.0 kernel because Postprocessor<T> has an Action property of the type Action<T, ISpecimenContext>. Just look at Ploeh.AutoFixtureUnitTest.Kernel.NodeComparer.PostprocessorEquatable.GetActionMethod<https://github.com/AutoFixture/AutoFixture/blob/master/Src/AutoFixtureUnitTest/Kernel/NodeComparer.cs#L262> and the big, ugle Apology<http://butunclebob.com/ArticleS.TimOttinger.ApologizeIncode> that accompanies it. I consider it one of the less fortunate design decisions in the AutoFixture code base.

AutoFakeItEasy may do something similar, but I see no reason to perpetuate a bad design decision.

—
Reply to this email directly or view it on GitHub<https://github.com/AutoFixture/AutoFixture/pull/54/files#r2521707>.