Use @microsoft/react-native-test-app as the defacto E2E test framework

[afoxman]

We should adopt @microsoft/react-native-test-app as the de facto test framework for E2E testing. It lets hosts pull in our code, the test framework, and a collection of react-native apps, and stitch them all up into a single test app. And everything is driven from data in the app manifests (test creation/execution).

To make this work, the app needs to express how it should be tested. For examples, what surfaces should the app be run in, and what are the initial props and dev settings to use when running the tests.

These test cases likely belong in the manifest. They should be stripped out when making a production/aggregated manifest, though, as they aren't used on client machines.

The first step is a discussion between @acoates-ms and @tido64 to agree on a manifest schema.

[tido64]

A summary of a quick discussion @acoates-ms and I had on our needs for React Native Test App.

We discussed one of the properties that we wanted to change, components. Currently, the components property is implemented as an object where the key corresponds to the registered app name, e.g.

"components": {
  "myApp1": {
    "presentationStyle": "modal",
    "moreProps": "values"
  },
  "myApp2": {
    "presentationStyle": "fullScreen",
    "moreProps": "differentValues"
  },
}

React Native Test App uses this property to populate the component list on the home screen. For each entry, there will be a corresponding button that, when pressed, will create a React root view with the provided properties.

The issues that we're seeing with the current schema is that:

1. It prevents users from declaring the same components with different presentation styles. Looking from the perspective of a developer/tester, it should be possible to invoke the same component with different properties. For instance, it would be great if we could invoke a contact card with different presentation styles and content so we can test possible use cases in addition to edge cases.
2. The order in which they are displayed on the home screen in React Native Test App is indetermined due to objects having no requirements on key order. We should be able to guarantee the order on every app boot. I think it makes sense to let users determine the order themselves. For instance, I should be able to have my most used cases on top. Additionally, if we're going to support merging of lists in the future, not being able to guarantee some kind of order is going to be a very frustrating experience for everyone.

We therefore propose that components should be a list instead:

"components": [
  {
    "uuid": "8d3fb241-b963-4f7c-81f2-c6c29d568323",
    "appKey": "myApp1",
    "presentationStyle": "modal",
    "moreProps": "values"
  },
  {
    "uuid": "d67342c0-616d-47e8-b999-0b457bade6d3",
    "appKey": "myApp1",
    "presentationStyle": "fullScreen",
    "moreProps": "differentValues"
  }
]

With a list, the order is guaranteed. We'll also need to introduce a UUID so they can be uniquely identified for the use case where we want to launch specific components outside of React Native Test App.

Another aspect we touched very briefly upon was how React Native Test App uses appKey to also being able launch native views (i.e. Fragment on Android and UIViewController on iOS). This is a bit of a misuse of the manifest and requires reflection which won't be possible to support on C++ based platforms. The reason we needed this in the first place is due to the lack of lifecycle events. We currently use it for brownfield experiences that require certain things to be in place on the native side prior to the very first invoke of the bridge. We recognize that this is something that needs to be solved but don't have any resolutions at this point in time.

For reference, we've documented our implementation of the manifest here: https://github.com/microsoft/react-native-test-app/wiki/Manifest-(app.json)

cc @arazabishov, @danrydholm

[arazabishov]

Would it be possible for C++ based platforms to codegen bindings to controllers instead of using reflection?