Created DefaultValueGenerator<T> class to handle construction of problematic types

[Pvlerick]

In #490, I mentioned that System.Net.IPAddress was also a problematic type that AutoFixture wasn't able to create.

I started out by creating a new type to handle IPAddress specifically just as CulstureInfo and Encoding (#512) were handled, but it very quickly looked like code duplication (rule of three, I guess).

So I went ahead and created a new generic type that has a constructor taking a default value and the Create method will always return that default value. I deleted the previous generators and moved relevant tests in the new class' tests.

Open questions:

• Does the DefaultValueGenerator name sound good? I started out with CustomGenerator but changed my mind half-way, naming is hard 😄
• Should the constructor take a lambda factory instead of a plain value, so that it can return a new instance every time if needed?

CC @tiesmaster

[adamchester]

Looks great @Pvlerick! It looks this is a breaking change, since the deleted classes are public. Would it make sense to keep those classes (either as-is, or use the new class as an implementation?).

[Pvlerick]

@adamchester you are totally right, it was heavy handed to delete these two 👎

What about marking them as obsolete?

[adamchester]

Obsolete sounds good.

[Pvlerick]

I marked both InvariantCultureGenerator and Utf8EncodingGenerator as Obsolete and removed their corresponding unit tests (based on what I could see in the history, this seems to be standard way to proceed to avoid the warnings in the test project).

[ploeh]

Do we need a new class for this? Isn't it enough to compose an ISpecimenBuilder like the following?

new FilteringSpecimenBuilder(
    new FixedBuilder(value),
    new ExactTypeSpecification(type)));

[Pvlerick]

Looks like it 👍

I will simplify tomorrow and update the PR.

[tiesmaster]

@Pvlerick: 👍

[adamchester]

Regarding Obsolete, I thought in the past we actually added #warning disable in the tests to suppress the warnings?

[ploeh]

in the past we actually added #warning disable in the tests to suppress the warnings

We still do. The code is still there, so should still be covered by tests, but we don't want the compiler warnings from our tests.

[Pvlerick]

I looked at another Obsolete marked type, DateTimeGenerator and in this case the tests were deleted. However that might be a bad example since it has the error flag in the Obsolete attribute.

In any event, I'll update the PR and restore the tests. Thank you for the guidance 👍

[ploeh]

The progression is this:

1. [Obsoloete, false], using #pragma warn disable 618. This can be done as soon as we detect the need to deprecate a type or member. It's not a breaking change, but rather advance warning to users that something's going to change. The sooner such a warning is published, the better.
2. [Obsolete, true]. At this point, code that uses the deprecated API can no longer compile, so there's no option but to delete the tests. This is a breaking change, so can only be done when we increment the major version of AutoFixture.
3. Delete the type or member. This is also a breaking change (I think), so should only be done when we increment the major version.

I think that DateTimeGenerator was deprecated already in AutoFixture 2; in AutoFixture 4 we can entirely delete it.

HTH

[Pvlerick]

Makes sense, thanks for clarifying.

I updated the pull request accordingly.

[ploeh]

Shouldn't there be a #pragma warning restore 618 here?

[Pvlerick]

Indeed, I missed it, thanks!

[Pvlerick]

@ploeh Fixed.

[adamchester]

👍

[ploeh]

Thank you for your contribution! It's now live as AutoFixture 3.40.0.