Document acceptance testing process

[brodycj]

In response to discussion in PR #91 (adding tvOS platform support)

/cc @dlowder-salesforce @dsyne

[brodycj]

Automatic testing

The existing test automation which I think needs some formal documentation is intended to ensure that code refactoring and other cleanup does not break working behavior. I generally use snapshots to capture the current behavior, which can be updated according to behavior changes as needed. The automatic testing is in the following parts under the tests subdirectory:

• with-injection - test behavior with mock objects injected through an undocumented part of the library API
• with-mocks - test some behavior using some mock Jest objects as needed - especially needed for testing with Windows (using generated uuids) and checking the console logging calls
• integration - test some end-to-end behavior running bin/cli.js in a separate process, in a very limited number of cases (this is only done to ensure that bin/cli.js which is now very limited is not broken by refactoring or other code cleanup)

Here are the main things that are needed to maintain the automatic testing:

• as I said before, do yarn jest -u or npx jest -u to update the tests if the behavior or generated output is updated
• whenever some new functionality is added such as adding a new option, add a new test to ensure it would not be broken by refactoring or other cleanup in the future
• major changes such as switching fs library may need test updates

I recently introduced Stryker mutation testing which seems to catch most cases of code not covered by the automatic testing (I discussed some exceptions in #89).

Manual release testing

Here are some sanity test cases that I run whenever I am ready to publish a new package release, with create-react-native-module installed using npm i -g github:brodybits/create-react-native-module#mybranchname:

• generated module with generated example works on Android & iOS on React Native 0.59 (example is generated using React Native 0.59 by default)
• generated view module (using --view option) with generated example works on Android & iOS
• generated module with generated example works on Android & iOS on React Native 0.60, which is the same as react-native@latest at this point (I use --example-react-native-version=react-native@latest in this case)
• generated view module with generated example works on Android & iOS on React Native 0.60 / react-native@latest (with an edit needed for generated view module to work on Android on React Native 0.60)
• now testing on React Native 0.61-rc (ref: #93)

(I am starting to skip some of these steps when I feel they are not all needed.)

I generally do similar manual testing, sometimes to a limited extent, before merging significant updates.

Motivation is to avoid making releases with stupid mistakes like #12.

There may be ways to do this automatically, using Sauce Labs for example. I think the existing manual and automatic testing process should be good enough for now (at least).

/cc @dlowder-salesforce @dsyne