Better AutoFixture support?

[Kralizek]

Hi!

AutoFixture is a great library for quickly building tests by assemblying test data.

One of the paradigms they support is the usage of test parameters as a way to receive the different parts of the test.

Here is an example

public class SomeHttpService
{
    public SomeHttpService(HttpClient client) { }

    public Task DoSomethingAsync() { }
}

[TestFixture]
public class SomeHttpServiceTests
{
    [Test, MyAutoData]
    public void A_test([Frozen] FakeHttpMessageHandler handler, SomeHttpService sut)
    {
        // customize options
        handler.Options.Add(new ...);

        sut.DoSomethingAsync();

        // verify sent request
        Assert.That(handler.Options[0].RequestUri, Is.EqualTo(something)
    }
}

Basically with this pattern, there is no direct access to the constructor and the FakeHttpMessageHandler can only be customized when it gets constructed.

[PureKrome]

:wave: @Kralizek

Hi there - sorry for the really late reply. But better late than never.

So here goes:

Basically with this pattern, there is no direct access to the constructor and the FakeHttpMessageHandler can only be customized when it gets constructed.

Ok - so if I understand what you are saying, it's this:

"Can there be a default constructor that takes -no arguments- so frameworks like AutoFixture can 'do their stuff'. Currently, all available constructors require an argument."

If this statement is correct then .. 🤔 hmmm.. I'm not sure.

Can we code it? sure can. Right now, to actually -do- anything with a FakeHttpMessageHandler requires us to have at least one thing setup. e.g. An HTTP Method or a Request Uri.

Basically, what would you think should happen if we do this? (pseduo code...)

// Arrange.
var handler = new FakeHttpMessageHandler(); // No options defined.
var httpClient = new HttpClient(handler);
var sut = new SomeHttpService(httpClient);

// Act.
await sut.DoSomethingAsync();

// Arrange
????

In the above example I wrote, we create a fake handler. Great. But we don't setup anything. So .. should this mean that we don't care at all what happens? It's like a catch-all sorta thingy fake-handler?

The code I currently have suggests the following: If you wish to create and use a fake handler, then you need to at least define one setup condition ... else why are you even using this fake handler?

I do understand that in your example above you do manually set the options (e.g. handler.Options.Add(new ...);) which is okay for you ... but I have to think about other users and .. of course .. when people incorrectly use/abuse the library. Or more to the point, how I can prevent accidentally abuse/incorrect use of the library, from occurring.

Thoughts?

[Kralizek]

@PureKrome an idea would be to have a default case (either 200 or 500) that works without any seutp...

[PureKrome]

I could definitely do that. 🤔

[Kralizek]

Anyway there is no need for a default constructor (although it might be better having it). The important thing is to have read/write access to the list of conditions.

[PureKrome]

Anyway there is no need for a default constructor

I thought you said AutoFac can't create an instance of the class because it requires an empty ctor?

The important thing is to have read/write access to the list of conditions.

What does this mean?

[Kralizek]

Anyway there is no need for a default constructor

I thought you said AutoFac can't create an instance of the class because it requires an empty ctor?

Please disregard my comment. AutoFixture can create an object without a parameterless constructor but the objects passed in the constructor are created by AutoFixture itself so it will have options filled with autogenerated values that might not be good for the tests.

The important thing is to have read/write access to the list of conditions.

What does this mean?

I meant being able to add a new (set of) options after the handler is created.

// customize options
handler.Options.Add(new ...);