verifytests / verify.http Goto Github PK

Preamble

❯ dotnet --list-sdks
6.0.402 [C:\Program Files\dotnet\sdk]
7.0.100 [C:\Program Files\dotnet\sdk]

Describe the bug

Given the following test

[Fact]
public async Task ExplicitContentEmptyArray()
{
    using var client = new MockHttpClient(
        content: @"{ ""anEmptyArray"": [] }",
        mediaType: "application/json");

    var result = await client.GetAsync("https://fake/get");

    await Verify(result);
}

The resulting snapshot looks likes the following (NOTE: Value is an empty object)

{
  Version: 1.1,
  Status: 200 OK,
  Content: {
    Headers: {
      Content-Type: application/json; charset=utf-8
    },
    Value: {}
  }
}

I would have expected:

{
  Version: 1.1,
  Status: 200 OK,
  Content: {
    Headers: {
      Content-Type: application/json; charset=utf-8
    },
    Value: {
      anArray: []
    }
  }
}

If the content returns a non empty array the snapshot looks correct:

[Fact]
public async Task ExplicitContentNonEmptyArray()
{
    using var client = new MockHttpClient(
        content: @"{ ""anArray"": [{ ""a"": ""b"" }] }",
        mediaType: "application/json");

    var result = await client.GetAsync("https://fake/get");

    await Verify(result);
}

Returns:

{
  Version: 1.1,
  Status: 200 OK,
  Content: {
    Headers: {
      Content-Type: application/json; charset=utf-8
    },
    Value: {
      anArray: [
        {
          a: b
        }
      ]
    }
  }
}

Is the feature request related to a problem

Using Verify.Http in a test project that targets netcoreapp3.1 causes the following warning to be displayed:

Warning	NU1701	Package 'Verify.Http 1.0.2' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8' instead of the project target framework '.NETCoreApp,Version=v3.1'. This package may not be fully compatible with your project.	

Describe the solution

Add netcoreapp3.1 to the list of TargetFrameworks.

This may possibly require some conditional logic on some of the other libraries being included to ensure they are 3.1-compatible

Is the feature request related to a problem

I was using this library and one of my HTTP requests returns a Zip file. When I looked at the verified file created I noticed that for the Zip response there was no response body captured.

Checking the code I noticed that the Verify.Http will not write to the verified file anything if the request/response content is not Text.

I was wondering if you thought it would be a good idea to lift this restriction and allow more than just text to be captured in the verified file ?

Describe the solution

If the body is not considered text I was thinking that perhaps this could be implemented by writing a base64 encoding of the bytes from the HttpContent ?

Additional context

1. I understand that the contents of the verified file wouldn't be human readable so it's already questionable if this brings enough value. For instance, if there's a diff how would you know if you actually want to take the diff or not when looking at a base64 value? I think here the answer is you wouldn't know, the fact that there is a diff in this scenario would just alert you to the fact that something changed and you would have to check in some other way whether you want to take the diff or not.

2. The size of the file verified file could also be something to be aware of. If the verified file now contained a base64 encoding of the bytes from the HttpContent then the size of the file could easily become significantly large. If this is an issue I believe that perhaps by default writing anything other than text could be disabled and an option to toggle it on in case the user wants to. Going one step further, there could also be an option to set a limit for the HttpContent to be recorded so that if for instance the Content-Length header or the length of the resulting base64 string is over X amount then that HttpContent would not be written to the verified file.

3. Also scrubbers wouldn't work when recording HttpContent that isn't text. So for scenarios where the HttpContent changes per test run this wouldn't be useful. But shouldn't also create a problem to users if it's something that can be toggled on/off.

What are your thoughts on this matter?

• System.Diagnostics.DiagnosticSource 7.0.0
• Microsoft.Extensions.DiagnosticAdapter 3.1.31
• Verify 19
• Microsoft.Extensions.Http 7

There is a problem when recording is disabled and there are others listeners to the HttpHandlerDiagnosticListener event.
This is happening because DiagnosticSource call all subscribers when there is more than one, it is ignoring the filter added on subscribe

To fix this is needed add a condition to check if Recording is enabled before call Recording.Add, I tried to create a new PR to fix this, but I could not create because I don't have permission to push.

Code to reproduce the error:

public class Tests
{
    static Tests()
    {
        VerifyHttp.Initialize();
    }

    [Fact]
    public async Task BrokenTest()
    {
        using var _ = DiagnosticListener.AllListeners.Subscribe(new MyListener());
        using var client = new HttpClient();
        using var response = await client.GetAsync("https://www.google.com/");
        await Verify(new { response.StatusCode });
    }

    public class MyListener : IObserver<DiagnosticListener>, IDisposable
    {
        private readonly ConcurrentQueue<IDisposable> subscriptions = [];

        public void Dispose()
        {
            foreach (var s in subscriptions)
            {
                s.Dispose();
            }
        }

        public void OnCompleted()
        {
        }

        public void OnError(Exception error)
        {
        }

        public void OnNext(DiagnosticListener value)
        {
            if (value.Name != "HttpHandlerDiagnosticListener")
                return;

            subscriptions.Enqueue(value.SubscribeWithAdapter(this));
        }

        [DiagnosticName("System.Net.Http.HttpRequestOut")]
        public void IsEnabled()
        {
        }

        [DiagnosticName("System.Net.Http.HttpRequestOut.Start")]
        public virtual void OnHttpRequestOutStart(HttpRequestMessage request)
        {
        }

        [DiagnosticName("System.Net.Http.HttpRequestOut.Stop")]
        public virtual void OnHttpRequestOutStop(HttpRequestMessage request, HttpResponseMessage response, TaskStatus status)
        {
        }
    }
}

Drop net48 and net6