-
Notifications
You must be signed in to change notification settings - Fork 9.7k
[integration_test] Add a run method for proper reporting of test results
#3179
Conversation
…sults This integrates with `directRunTests` from `package:test_core`, and allows users to use `test()` to wrap their tests, instead of only supporting `testWidgets()` and failing silently otherwise. In addition, exceptions thrown in other lifecycle blocks such as `setUp` will be caught and reported. This is a non-breaking change, so the existing reporting mechanism will continue to work. A global variable is used to ensure that using `run` will disable the existing reporting mechanism. Fixes #50816.
jiahaog
left a comment
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.
Sending this draft for review first for preliminary feedback – this is still pending a release from package:test_core so that we can use directRunTests.
I also want to restructure the tests a bit, and do a bit more testing locally to ensure that nothing is broken
| }, | ||
| ); | ||
| } on MissingPluginException { | ||
| print('Warning: integration_test test plugin was not detected.'); |
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 this should be treated as a more serious failure, and probably make us exit with some non-zero exit code.
The risk is that if this isn't set up right in the application, it will print what looks like a warning in a sea of log output and exit with zero when tests may have failed.
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.
We don't want the application to exit when it is invoked using flutter driver, as the native plugin is not used. The platform side plugin is only used when running with FTL or through Xcode. The responsibility of failing when the infrastructure is not set up properly (i.e. the native plugin is not installed) should probably be up to the host side invoker though, and probably not here.
| import 'package:test_core/src/runner/engine.dart'; | ||
| import 'package:test_core/src/runner/reporter.dart'; |
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.
This will give warnings right?
We should probably pin the dependency for this to make sure we don't inadventently get broken by a patch release that changes internals.
I'm also surprised we don't need analysis ignores here, like // ignore: implementation_import or something. We should enable that lint and add the ignore here.
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.
Yeah the lint isn't set up for this. This is a bit out of scope of this PR though – I have started #3187 to see if we can turn on the lint. There are some existing violation for this lint in the repo, will follow up tomorrow.
| liveTest.test.name: liveTest.state.result.name == success | ||
| ? success | ||
| : Failure( | ||
| liveTest.test.name, liveTest.errors.first.stackTrace.toString(), |
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.
Is the first stack trace the right one?
Is the first error the right one?
Is there some way we could add all stack traces and errors to the reporting?
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.
This was taken from the way other Dart tests are integrated with the Google3 infrastructure. I'm not sure if we should do anything else, @natebosch would you know more about this?
| flutter_test: | ||
| sdk: flutter | ||
| path: ^1.6.4 | ||
| test_core: |
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.
@jakemac53 @natebosch - LGTY?
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.
This can be updated now
| test_core: | |
| test_core: 0.3.12-nullsafety.6 |
Unfortunately null safety leaves us in a state where we'll need to pin to a single version since we can't really pin to a feature version currently.
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.
Thanks, I updated it but there's a conflict with flutter_test that is pinned to the previous version. I have opened flutter/flutter#68771 to update that separately.
dnfield
left a comment
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.
This is pretty exciting - this will fix several classes of problems users can run into currently with the package!
|
Still pending flutter/flutter#68771 for CI to pass, but this is ready for review now. |
|
package:integration_test is being moved to the SDK repo, so this PR is superseded by flutter/flutter#70075 |
Description
This integrates with
directRunTestsfrompackage:test_core, and allows users to usetest()to wrap their tests, instead of only supportingtestWidgets()and failing silently otherwise. In addition, exceptions thrown in other lifecycle blocks such assetUpwill be caught and reported.This is a non-breaking change, so the existing reporting mechanism will continue to work. A global variable is used to ensure that using
runwill disable the existing reporting mechanism.Example usage
But we will want to make it easier for users to use this API. A CLI will be added as a follow up PR to wrap this method as part of flutter/flutter#66264, so users can write the following instead, and the CLI will take care of wrapping the users' script with
runappropriately.Related Issues
Fixes flutter/flutter#50816.
Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?