-
Notifications
You must be signed in to change notification settings - Fork 9.8k
[e2e] Fix incorrect test results when one test passes then another fails #2866
Conversation
For example, the following test will result in an error reported for the first test case. ``` void main() { testWidgets('a test that passes', (tester) async { expect(true, true); }); testWidgets('a test that fails', (tester) async { expect(true, false); }); } ``` We need to reset `reportTestException` back to the previous value after completion of `runTest`, or repeated failures will cause the exception handler for a previous test to be invoked, as they "stack". Instead of reseting it, however, do this once in the constructor because the test description is already provided by the function signature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the change makes sense, but could you please add a test that would have failed without this?
I realize this might require actually running some tests and parsing the output.
Going to land this on the understanding that CI is red because of issues upstream in Flutter that have been resolved. |
Sorry, commented on wrong PR... |
Done, but this approach does slow down the tests significantly as it has to start up the flutter tester for each test in a child process. One thing I'm not sure of is assuming |
…ils (flutter#2866) * [e2e] Fix incorrect test results when one test passes then another fails For example, the following test will result in an error reported for the first test case. ``` void main() { testWidgets('a test that passes', (tester) async { expect(true, true); }); testWidgets('a test that fails', (tester) async { expect(true, false); }); } ``` We need to reset `reportTestException` back to the previous value after completion of `runTest`, or repeated failures will cause the exception handler for a previous test to be invoked, as they "stack". Instead of reseting it, however, do this once in the constructor because the test description is already provided by the function signature. * Add a mechanism for testing test results
…ils (flutter#2866) * [e2e] Fix incorrect test results when one test passes then another fails For example, the following test will result in an error reported for the first test case. ``` void main() { testWidgets('a test that passes', (tester) async { expect(true, true); }); testWidgets('a test that fails', (tester) async { expect(true, false); }); } ``` We need to reset `reportTestException` back to the previous value after completion of `runTest`, or repeated failures will cause the exception handler for a previous test to be invoked, as they "stack". Instead of reseting it, however, do this once in the constructor because the test description is already provided by the function signature. * Add a mechanism for testing test results
…ils (flutter#2866) * [e2e] Fix incorrect test results when one test passes then another fails For example, the following test will result in an error reported for the first test case. ``` void main() { testWidgets('a test that passes', (tester) async { expect(true, true); }); testWidgets('a test that fails', (tester) async { expect(true, false); }); } ``` We need to reset `reportTestException` back to the previous value after completion of `runTest`, or repeated failures will cause the exception handler for a previous test to be invoked, as they "stack". Instead of reseting it, however, do this once in the constructor because the test description is already provided by the function signature. * Add a mechanism for testing test results
Description
For example, the following test will result in an error reported for the first test case.
We need to reset
reportTestException
back to the previous value after completion ofrunTest
, or repeated failures will cause the exception handler for a previous test to be invoked, as they "stack". Instead of reseting it, however, do this once in the constructor because the test description is already provided by the function signature.Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?