Fixture creates OmitSpecimens instead of default values

[sshushliapin]

In the OmitSpecimen documentation:

A signal type used to indicate to the Auto-Property feature that a given request should be
ignored, and no further processing performed.

Despite the explicit mentioning the Auto-Property feature here (which indicates that we're talking about specimen 'parts'), I have a strong feeling that the following test should pass:

[Test]
public void CreateWithOmittedRequestReturnsNull()
{
    var fixture = new Fixture();
    var overallOmitter = new Omitter(new TrueRequestSpecification());
    fixture.Customizations.Insert(0, overallOmitter);

    var result = fixture.Create<object>();

    Assert.IsNotInstanceOf<OmitSpecimen>(result); // fails
    Assert.Null(result);
}

[ploeh]

I don't think I even have an opinion on that matter 😳

There are some parts of the design of AutoFixture that, if you start doing weird things to it, will compile, but not necessarily do meaningful things at run-time. That's one disadvantage of an API which is, to be frank, quite weakly typed.

Is there an underlying reason for this issue?

[sshushliapin]

Yep, the question itself sounds a bit strange but there is a reason :)

I think the issue #343 can be solved using an omitter that would ignore the test method parameters with the NUnit's ValuesAttribute.

I'm experimenting with that here and now end up with the following exception:

[Test, AutoData]
public void FixtureIgnoresParameterWithValuesAttribute([Values(1, -1)] int num)
{
    Assert.True(num == -1 || num == 1);    // fails
    // System.ArgumentException : Unable to cast  "Ploeh.AutoFixture.Kernel.OmitSpecimen" 
    // to "System.Int32".
}

//cc: @steph4nc

[sshushliapin]

I was wrong, the omitter won't solve the issue #343 (there is another fix required), so if there is no other scenario when this particular fix could be used, I'm fine with closing the issue.

an API which is, to be frank, quite weakly typed.

@ploeh, that is not the first time you mentioning this. It would be so great to know which parts you're talking about and whether it'll be improved in v4 :)
Thanks!

[ploeh]

It would be so great to know which parts you're talking about and whether it'll be improved in v4

It'd be a stretch to call this strongly typed:

public interface ISpecimenBuilder
{
    object Create(object request, ISpecimenContext context);
}

or this:

public interface ISpecimenCommand
{
    void Execute(object specimen, ISpecimenContext context);
}

I don't plan on changing it in version 4, though. It'd basically mean a rewrite if I were to change it, and in the end, I'd probably end up with FsCheck anyway, so I see no reason to do that...

[ploeh]

Is there anything else regarding this issue that ought to be addressed?

[sshushliapin]

Nope. Closed.