feat: adding shorebird specific tests #45
Conversation
| import 'package:meta/meta.dart'; | ||
| import 'package:test/test.dart'; | ||
|
|
||
| File get _flutterBinaryFile => File( |
There was a problem hiding this comment.
Doc comments throughout this file would be useful. Here: "this assumes we're running from (path)" or similar
| dependencies: | ||
| archive: ^3.5.1 | ||
| path: ^1.9.0 |
There was a problem hiding this comment.
Yeah,
path is used here for example: https://github.com/shorebirdtech/flutter/pull/45/files#diff-f89684ff9eb7b28bb4625302b31d2c083d33414ed9bde6331f7991098896b412R15
and archive is used here: https://github.com/shorebirdtech/flutter/pull/45/files#diff-f89684ff9eb7b28bb4625302b31d2c083d33414ed9bde6331f7991098896b412R189
|
|
||
| void main() { | ||
| group('shorebird helpers', () { | ||
| testWithShorebirdProject('can build a base project', |
There was a problem hiding this comment.
yeah, in theory we don't, but I kind like having basic ones like that cause it makes it easier to track down a test that broke in an "earlier" layer.
Happy to remove them if you think they just "fill up space"
Co-authored-by: Felix Angelov <felix@shorebird.dev>
We do a couple of customizations in the flutter framework build pipeline. Like manipulating the
shorebird.yamlthat is bundled in the buildflutter_assetsfolder when there is a flavor, or when a public key for patch signing is provided through an environment variable.But there were no tests to assert in that behaviour.
Since the pipeline can be a bit complex, the approach proposed in this PR is to write some sort of integration tests for these customizations that we do.
These integration tests are unique to Shorebird, the repository already include a folder called
integration_test, but AFAIK, that folder is about flutter integration test features, so the choice were to create a newshorebird_testpackage, which is intended to house tests of behaviours included in the framework that are related to the mentioned customizations.