Widget tests overriding HTTP to return 400 is incredibly confusing and unintuitive

[tomgilder]

I’ve just lost several hours of debugging to this issue.

If you have a test file like this, the HTTP test passes:

import 'package:flutter_test/flutter_test.dart';
import 'package:http/http.dart';

void main() {
   test("HTTP request", () async {
    final result = await get(Uri.http("flutter.dev", "/"));
    expect(result.statusCode, 200);
  });
}

But adding even an empty widget test in the same file causes the HTTP test to fail - even if you just run the HTTP test:

import 'package:flutter_test/flutter_test.dart';
import 'package:http/http.dart';

void main() {
   test("HTTP request", () async {
    final result = await get(Uri.http("flutter.dev", "/"));
    expect(result.statusCode, 200);
  });

  testWidgets("Empty widget test", (tester) async { });
}

There’s nothing in the log or the faked HTTP response to indicate that Flutter in intercepting the response. It’s deeply unintuitive that just the presence of testWidgets - without the widget test even being run - would cause HTTP intercepting.

I also can’t find anything in the documentation about the intercepting.

Suggestions:

• Don’t do the HTTP intercepting by default - make it so developers explicitly enable it
• If that’s too much of a breaking change, at the very least document it
• If possible, log that the HTTP interception is enabled
• Add a message to the faked HTTP response explicitly saying it’s a fake response, why it’s been faked, and how to disable it

[Starcarr]

I want to piggy back on this to add: there doesn't seem to be a way to actually do the HTTP request at all. I understand why you would want to discourage it, but in my team's case, we are using mock_web_server and we would rather mock the server than the client – we are already doing that with the Driver and Unit tests without issue, so it only seems confusing that we can't do it for Widget tests.

Now we are faced with either not having Widget tests that do HTTP requests, moving everything we already have to mockito (which we would rather not since it involves a lot of boilerplate), or having 1/3 of the tests using mockito and the other 2/3 using mock_web_server.

I hope the Flutter team will allow devs to enable actual HTTP requests for Widget test – so that we can decide between mocking the server or the client – and document how to do it.

Btw, we are adding Widget tests since Driver tests don't have the option to generate coverage reports, see this – if we had coverage with Driver tests we could live with those for now.

[anaisbetts]

+1, just got bit by this. Though now that I stomped it via HttpOverrides.global = null, I'm starting to understand why they did it. Because everything async is mocked in testWidgets (see https://stackoverflow.com/questions/49581157/flutter-tests-waiting-for-a-certain-duration), it's actually not easy to wait for the request to complete properly

[neokree]

I also found this problematic, in my app I moved from widget test to integration tests to be able to fake the server. However searching for a way to handle image loading in widget tests I found this answer on SO.

Looking in the library code I found that the HTTP interceptor can be overridden (code here] and is possible to mock the http response without injecting the "mock client" in the app.

This, at least to me, could allow to revert back my integration tests to widget tests.

[PavelPZ]

Uff, the same for me (spent hours of debugging). No documentation, no warning :-(

[dnfield]

TestWidgets overrides global HTTP settings to always return 400 on http requests.

We should document this better, and we should try to give you a better error when it happens.

The idea is that you should not be making network calls in a test.