From b68e060e62f0d7bc6625fdca30db17d64b24e7fe Mon Sep 17 00:00:00 2001 From: Lorenzo Sciandra Date: Thu, 6 Jul 2023 16:14:04 +0100 Subject: [PATCH 01/10] add rfc - starting point --- proposals/0000-adding-e2e-in-core.md | 73 ++++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 proposals/0000-adding-e2e-in-core.md diff --git a/proposals/0000-adding-e2e-in-core.md b/proposals/0000-adding-e2e-in-core.md new file mode 100644 index 00000000..683c9e8a --- /dev/null +++ b/proposals/0000-adding-e2e-in-core.md @@ -0,0 +1,73 @@ +--- +title: Introducing E2E testing in React Native core +author: +- Lorenzo Sciandra +- Nicola Corti +- Riccardo Cipolleschi +- +date: 2023-07-06 +--- + +# RFC0000: Introducing E2E testing in React Native core + +## Summary + +Testing is how we validate that the code is solid, and ensure that what we build our products on top of is solid and our customers are happy. + +For the longest time, in React Native core this validation has been done in a few ways: + +* via Meta using the source code in their own products first +* via internal testing in the Meta monorepo +* via (mostly) unit testing on the CircleCI GitHub react-native repo +* via local testing by the release crew ahead of generating new releases +* via "pre-stable" releases (AKA Release Candidates and nightlies) that members from the community could use to test and report back + +There is a great opportunity for improvement here, by introducing End-to-End testing in the CircleCI GitHub react-native repository to introduce one more level of validation that aims to replace the need for (at least) the local testing from the release crew. By adding tooling that spins up the RNTester app in the codebase, and "black box" (the RNTester app is not aware that the agent using it is not a human) testing it, we can trust that the code is more solid. + +This will make the codebase more stable, surface issues rapidly to the commit authors, and reduce the workload for the release crew. + +## Basic example + +If the proposal involves a new or changed API, include a basic code example. Omit this section if it's not applicable. + +## Motivation + +Why are we doing this? What use cases does it support? What is the expected outcome? + +Please focus on explaining the motivation so that if this RFC is not accepted, the motivation could be used to develop alternative solutions. In other words, enumerate the constraints you are trying to solve without coupling them too closely to the solution you have in mind. + +## Detailed design + +This is the bulk of the RFC. Explain the design in enough detail for somebody familiar with React Native to understand, and for somebody familiar with the implementation to implement. This should get into specifics and corner-cases, and include examples of how the feature is used. Any new terminology should be defined here. + +## Drawbacks + +Why should we _not_ do this? Please consider: + +- implementation cost, both in term of code size and complexity +- whether the proposed feature can be implemented in user space +- the impact on teaching people React Native +- integration of this feature with other existing and planned features +- cost of migrating existing React Native applications (is it a breaking change?) + +There are tradeoffs to choosing any path. Attempt to identify them here. + +## Alternatives + +What other designs have been considered? Why did you select your approach? + +## Adoption strategy + +If we implement this proposal, how will existing React Native developers adopt it? Is this a breaking change? Can we write a codemod? Should we coordinate with other projects or libraries? + +## How we teach this + +What names and terminology work best for these concepts and why? How is this idea best presented? As a continuation of existing React patterns? + +Would the acceptance of this proposal mean the React Native documentation must be re-organized or altered? Does it change how React Native is taught to new developers at any level? + +How should this feature be taught to existing React Native developers? + +## Unresolved questions + +Optional, but suggested for first drafts. What parts of the design are still TBD? From a8901e1ae9e5fc2dd8ff178c3d23f6602c813e6b Mon Sep 17 00:00:00 2001 From: Lorenzo Sciandra Date: Mon, 10 Jul 2023 11:25:30 +0100 Subject: [PATCH 02/10] tweaks --- ...0-adding-e2e-in-core.md => 0684-adding-e2e-in-core.md} | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) rename proposals/{0000-adding-e2e-in-core.md => 0684-adding-e2e-in-core.md} (81%) diff --git a/proposals/0000-adding-e2e-in-core.md b/proposals/0684-adding-e2e-in-core.md similarity index 81% rename from proposals/0000-adding-e2e-in-core.md rename to proposals/0684-adding-e2e-in-core.md index 683c9e8a..692e9438 100644 --- a/proposals/0000-adding-e2e-in-core.md +++ b/proposals/0684-adding-e2e-in-core.md @@ -8,21 +8,21 @@ author: date: 2023-07-06 --- -# RFC0000: Introducing E2E testing in React Native core +# RFC0684: Introducing E2E testing in React Native core ## Summary -Testing is how we validate that the code is solid, and ensure that what we build our products on top of is solid and our customers are happy. +Testing is how we validate that the code is good, and ensure that what we build our products on top of is solid and our customers are happy. For the longest time, in React Native core this validation has been done in a few ways: * via Meta using the source code in their own products first -* via internal testing in the Meta monorepo +* via internal testing with custom tooling in the Meta monorepo * via (mostly) unit testing on the CircleCI GitHub react-native repo * via local testing by the release crew ahead of generating new releases * via "pre-stable" releases (AKA Release Candidates and nightlies) that members from the community could use to test and report back -There is a great opportunity for improvement here, by introducing End-to-End testing in the CircleCI GitHub react-native repository to introduce one more level of validation that aims to replace the need for (at least) the local testing from the release crew. By adding tooling that spins up the RNTester app in the codebase, and "black box" (the RNTester app is not aware that the agent using it is not a human) testing it, we can trust that the code is more solid. +There is a great opportunity for improvement here, by introducing End-to-End (E2E) testing in the CircleCI GitHub react-native repository to introduce one more level of validation that aims to replace the need for (at least) the local testing from the release crew. By adding tooling that spins up the RNTester app in the codebase, and "black box" (the RNTester app is not aware that the agent using it is not a human) testing it, we can trust that the code is more solid. This will make the codebase more stable, surface issues rapidly to the commit authors, and reduce the workload for the release crew. From c063172ece72159ed4c437cc3b3ad74949ebfa3c Mon Sep 17 00:00:00 2001 From: Lorenzo Sciandra Date: Mon, 10 Jul 2023 16:18:47 +0100 Subject: [PATCH 03/10] checkpoint --- proposals/0684-adding-e2e-in-core.md | 82 ++++++++++++++++++---------- 1 file changed, 53 insertions(+), 29 deletions(-) diff --git a/proposals/0684-adding-e2e-in-core.md b/proposals/0684-adding-e2e-in-core.md index 692e9438..943aba00 100644 --- a/proposals/0684-adding-e2e-in-core.md +++ b/proposals/0684-adding-e2e-in-core.md @@ -1,10 +1,10 @@ --- title: Introducing E2E testing in React Native core author: -- Lorenzo Sciandra -- Nicola Corti -- Riccardo Cipolleschi -- + - Lorenzo Sciandra + - Nicola Corti + - Riccardo Cipolleschi + - date: 2023-07-06 --- @@ -16,58 +16,82 @@ Testing is how we validate that the code is good, and ensure that what we build For the longest time, in React Native core this validation has been done in a few ways: -* via Meta using the source code in their own products first -* via internal testing with custom tooling in the Meta monorepo -* via (mostly) unit testing on the CircleCI GitHub react-native repo -* via local testing by the release crew ahead of generating new releases -* via "pre-stable" releases (AKA Release Candidates and nightlies) that members from the community could use to test and report back +- via Meta using the source code in their own products first +- via internal testing with custom tooling in the Meta monorepo +- via (mostly) unit testing on the CircleCI GitHub `react-native` repo +- via local testing by the release crew ahead of generating new releases +- via "pre-stable" releases (AKA Release Candidates and nightlies) that members from the community could use to test and report back -There is a great opportunity for improvement here, by introducing End-to-End (E2E) testing in the CircleCI GitHub react-native repository to introduce one more level of validation that aims to replace the need for (at least) the local testing from the release crew. By adding tooling that spins up the RNTester app in the codebase, and "black box" (the RNTester app is not aware that the agent using it is not a human) testing it, we can trust that the code is more solid. +There is a great opportunity for improvement here, by introducing End-to-End (E2E) testing in the CircleCI GitHub `react-native` repository to introduce one more level of validation that aims to replace the need for (at least) the local testing from the release crew. By adding tooling that spins up the RNTester app in the codebase, and "black box" (the RNTester app is not aware that the agent using it is not a human) testing it, we can trust that the code is more solid. This will make the codebase more stable, surface issues rapidly to the commit authors, and reduce the workload for the release crew. ## Basic example -If the proposal involves a new or changed API, include a basic code example. Omit this section if it's not applicable. +On a basic level, the idea is to have fully automated end-to-end testing running on CircleCI on `react-native`'s every single commit to flag if any code change is inadvertently introducing a regression of some form. + +The code and tests to do so will live in a new dedicated monorepo package, `packages/rn-tester-e2e` and rely on the existing `RNTester` test app. + +The tooling combination selected for this is composed of [Appium](https://appium.io/) and [WebDriverIO](https://webdriver.io/) and [Jest](https://jestjs.io/). ## Motivation -Why are we doing this? What use cases does it support? What is the expected outcome? +The main "why" has already been explained above: introducing more solid automation to thoroughly verify that code changes don't introduce regressions. This will lead to removing the need for the release crew to do local testing to validate the code before a release. + +Another explanation necessary is the stack decision: the reason is that it's the combination that gets the closest to the specific requirements of React Native's unique structure. We needed to fulfil these needs: + +- had to be "vanilla Jest" based + - in order to very closely match the internal Meta monorepo tooling used by the engineers, and in doing so lower the barrier to entry to add tests for this set too +- had to not touch RNTester code (pure black box testing) +- needed to support device farm + - while in a first phase the testing will run on CI on emulator/simulators, we are aware of the inherit flakyness so we want to start using a device farm relatively soon during the work on this effort +- easy to extend to out of tree platforms (ex. Windows, macOS) + - RNWindows already uses [a very similar stack](https://github.com/microsoft/react-native-windows/blob/main/docs/e2e-testing.md). -Please focus on explaining the motivation so that if this RFC is not accepted, the motivation could be used to develop alternative solutions. In other words, enumerate the constraints you are trying to solve without coupling them too closely to the solution you have in mind. +With that specific combination of needs, Appium+WBIO+Jest came out as the only viable option. ## Detailed design -This is the bulk of the RFC. Explain the design in enough detail for somebody familiar with React Native to understand, and for somebody familiar with the implementation to implement. This should get into specifics and corner-cases, and include examples of how the feature is used. Any new terminology should be defined here. +### ADD ME ## Drawbacks -Why should we _not_ do this? Please consider: +- CI will get slower because we are introducing new jobs to the pipelines. +- during the first iteration, only on CI, tests might be flaky. +- it will take a lot of time before the whole RNTester surface area will be covered with E2E tests. -- implementation cost, both in term of code size and complexity -- whether the proposed feature can be implemented in user space -- the impact on teaching people React Native -- integration of this feature with other existing and planned features -- cost of migrating existing React Native applications (is it a breaking change?) +## Alternatives -There are tradeoffs to choosing any path. Attempt to identify them here. +There are not many tools in the end to end space when it comes to React Native; of the known alternatives, neither of the following fitted our needs: -## Alternatives +- [Detox by Wix](https://github.com/wix/Detox) + - greybox testing + - no support for device farms +- [Maestro](https://github.com/mobile-dev-inc/maestro) + - yaml based testing + - only iOS/Android + - doesn't support device farms (unclear?) -What other designs have been considered? Why did you select your approach? +> ⚠️ This does not mean, obviously, that these are not good tools and you should not use them in your projects! But that simply for our specific requirements, they weren't viable options. ## Adoption strategy -If we implement this proposal, how will existing React Native developers adopt it? Is this a breaking change? Can we write a codemod? Should we coordinate with other projects or libraries? +This proposal doesn't directly affect consumers of React Native, only contributors and commit authors. -## How we teach this +The current roadmap is as follows: -What names and terminology work best for these concepts and why? How is this idea best presented? As a continuation of existing React patterns? +- a first PR, introducing the core infrastructure for E2E with documentation and CI integration, is prepared and merged + - This is already in the works, check out [the dedicated PR](https://github.com/facebook/react-native/pull/36267) +- after that one is merged, an umbrella issue is created (similar to the one for [the codegen](https://github.com/facebook/react-native/issues/34872), or [Kotlin](https://github.com/facebook/react-native/issues/37708)) to ask the community to contribute by adding tests in order to cover the whole RNTester surface area. +- while the test get added and the coverage grows, there are two stretch goals that will be pursued: + - adding a device farm as testing environment so to replace the need for using emulators and simulators on CI + - expand the toolset to cover also for screenshot testing + - this is current still being investigated (might end up having its own RFC), some tooling that was looked at was [`jest-image-snapshot`](https://github.com/americanexpress/jest-image-snapshot) -Would the acceptance of this proposal mean the React Native documentation must be re-organized or altered? Does it change how React Native is taught to new developers at any level? +## How we teach this -How should this feature be taught to existing React Native developers? +### ADD ME ## Unresolved questions -Optional, but suggested for first drafts. What parts of the design are still TBD? +This proposal lives in a bit of a peculiar state because it's been written 6 months after the core investigation and decision have been taken - so there isn't much unresolved at this point. Leaving this phrase here anyway in case on the RFC someone wants to add something. From daa45b3881849bcfe2b2c67c09ee31b446197d3a Mon Sep 17 00:00:00 2001 From: Lorenzo Sciandra Date: Tue, 11 Jul 2023 16:15:21 +0100 Subject: [PATCH 04/10] fill teaching section --- proposals/0684-adding-e2e-in-core.md | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/proposals/0684-adding-e2e-in-core.md b/proposals/0684-adding-e2e-in-core.md index 943aba00..439c41b6 100644 --- a/proposals/0684-adding-e2e-in-core.md +++ b/proposals/0684-adding-e2e-in-core.md @@ -67,10 +67,11 @@ There are not many tools in the end to end space when it comes to React Native; - [Detox by Wix](https://github.com/wix/Detox) - greybox testing - no support for device farms + - no desktop platforms support - [Maestro](https://github.com/mobile-dev-inc/maestro) - yaml based testing - - only iOS/Android - - doesn't support device farms (unclear?) + - no desktop platforms support + - no support for device farms (unclear?) > ⚠️ This does not mean, obviously, that these are not good tools and you should not use them in your projects! But that simply for our specific requirements, they weren't viable options. @@ -90,7 +91,13 @@ The current roadmap is as follows: ## How we teach this -### ADD ME +Because this proposal doesn't directly affect consumers of React Native, the need for "teaching content" is scoped to people who wants to learn more about this infrastructure is set up and they want to contribute with more tests. + +The first place where this type of documentation will be added is the readme of the dedicated new folder, `packages/rn-tester-e2e/README.md` *(you can already check out a draft of it [in the first PR](https://github.com/mateuszm22/react-native/blob/k+m/new-rn-tester-E2E/packages/rn-tester-e2e/README.md) already in the works)*. In this file, there are going to be information on how the setup works, how to test it locally and how to add new tests. + +Building on top of that, an umbrella issue will be created to coordinate and provide actionable examples for how to add new tests. In it, a streamlined explanation will be provided that will then reference back to the dedicated `packages/rn-tester-e2e/README.md`. + +And, of course, we can also point people to this RFC for more context/historical details. ## Unresolved questions From 82b33d788c43aba15e1327327457b5c9356a74f6 Mon Sep 17 00:00:00 2001 From: Lorenzo Sciandra Date: Tue, 11 Jul 2023 16:56:16 +0100 Subject: [PATCH 05/10] add detailed proposal --- proposals/0684-adding-e2e-in-core.md | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/proposals/0684-adding-e2e-in-core.md b/proposals/0684-adding-e2e-in-core.md index 439c41b6..e8e2de7b 100644 --- a/proposals/0684-adding-e2e-in-core.md +++ b/proposals/0684-adding-e2e-in-core.md @@ -52,7 +52,27 @@ With that specific combination of needs, Appium+WBIO+Jest came out as the only v ## Detailed design -### ADD ME +As already mentioned, the core stack involved is composed of [Appium](https://appium.io/) and [WebDriverIO](https://webdriver.io/) and [Jest](https://jestjs.io/). + +The dedicated code configuring the tooling and the tests will be in its own private package in `packages/rn-tester-e2e`. The app used for testing is RNTester (in `packages/rn-tester`), an app already present in the codebase which contains code for every component and API with sample implementations. + +In it, the `tests` folder is where the tests and referencing files all live. The substructure is as follows: + +- `screens` -> in this folder, you will find `*.screen.js` files, where each file represents a navigation screen for RNTester. So there are 3 root ones (`apis`, `bookmarks`, `components`) and then for subscreens, there's a folder with the same name. Each of these files provide an easy way to define all elements present in said screen, so that they can be used for tests. + - for each element of a given screen there will be a platform-specific reference in the form of + + ```js + btnSubmitElement: Utils.platformSelect({ + ios: iOSLabel('Press to submit your application!'), + android: androidWidget('Button', 'resource-id', 'button_default_styling'), + }), + ``` + + we did, during early investigations, attempt to figure out more streamlined and universal solutions, such as relying on accessibility labels like `testID`s, but it created inconsistent scenarios nor every element on screen always had a `testID` available. +- `specs` -> this folder follows a similar 1:1 mapping to the RNTester screens, but for the tests: for each screen (or subscreen) there's a dedicated `*.test.js` file (such as `buttonComponentScreen.test.js`). Ideally, in this file the Jest tests are standard, leveraging the `*.screen.js` counterpart for the details of defining how Appium/WDIO can reach those elements on screen. +- `helpers` -> where utility code, such as methods for checking element existence, clicking interaction, etc. will live + +These tests will be ran on the existing CircleCI infrastructure already set up for `react-native` on GitHub, so we will need to add two new dedicated jobs for E2E testing, `test_e2e_ios` and `test_e2e_android` and add them to the existing workflows that run on every commit. ## Drawbacks @@ -93,7 +113,7 @@ The current roadmap is as follows: Because this proposal doesn't directly affect consumers of React Native, the need for "teaching content" is scoped to people who wants to learn more about this infrastructure is set up and they want to contribute with more tests. -The first place where this type of documentation will be added is the readme of the dedicated new folder, `packages/rn-tester-e2e/README.md` *(you can already check out a draft of it [in the first PR](https://github.com/mateuszm22/react-native/blob/k+m/new-rn-tester-E2E/packages/rn-tester-e2e/README.md) already in the works)*. In this file, there are going to be information on how the setup works, how to test it locally and how to add new tests. +The first place where this type of documentation will be added is the readme of the dedicated new folder, `packages/rn-tester-e2e/README.md` _(you can already check out a draft of it [in the first PR](https://github.com/mateuszm22/react-native/blob/k+m/new-rn-tester-E2E/packages/rn-tester-e2e/README.md) already in the works)_. In this file, there are going to be information on how the setup works, how to test it locally and how to add new tests. Building on top of that, an umbrella issue will be created to coordinate and provide actionable examples for how to add new tests. In it, a streamlined explanation will be provided that will then reference back to the dedicated `packages/rn-tester-e2e/README.md`. From a80ec24eb977796b4c70607b415b32a184605a14 Mon Sep 17 00:00:00 2001 From: Lorenzo Sciandra Date: Fri, 21 Jul 2023 15:50:57 +0100 Subject: [PATCH 06/10] address feedback --- proposals/0684-adding-e2e-in-core.md | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/proposals/0684-adding-e2e-in-core.md b/proposals/0684-adding-e2e-in-core.md index e8e2de7b..cc26de7e 100644 --- a/proposals/0684-adding-e2e-in-core.md +++ b/proposals/0684-adding-e2e-in-core.md @@ -36,7 +36,9 @@ The tooling combination selected for this is composed of [Appium](https://appium ## Motivation -The main "why" has already been explained above: introducing more solid automation to thoroughly verify that code changes don't introduce regressions. This will lead to removing the need for the release crew to do local testing to validate the code before a release. +The main "why" has already been explained above: introducing more solid automation to thoroughly verify that code changes don't introduce regressions. + +This will lead to removing the need for the release crew to do manual local testing to validate the code before a release, which by being an human operation can lead to flukes. Additionally, this means that the time-to-release will get shorter because the release crew won't need to run those tests. Another explanation necessary is the stack decision: the reason is that it's the combination that gets the closest to the specific requirements of React Native's unique structure. We needed to fulfil these needs: @@ -58,6 +60,14 @@ The dedicated code configuring the tooling and the tests will be in its own priv In it, the `tests` folder is where the tests and referencing files all live. The substructure is as follows: + ```md + rn-tester-e2e + └──tests + ├── screens + ├── specs + └── helpers + ``` + - `screens` -> in this folder, you will find `*.screen.js` files, where each file represents a navigation screen for RNTester. So there are 3 root ones (`apis`, `bookmarks`, `components`) and then for subscreens, there's a folder with the same name. Each of these files provide an easy way to define all elements present in said screen, so that they can be used for tests. - for each element of a given screen there will be a platform-specific reference in the form of @@ -69,6 +79,9 @@ In it, the `tests` folder is where the tests and referencing files all live. The ``` we did, during early investigations, attempt to figure out more streamlined and universal solutions, such as relying on accessibility labels like `testID`s, but it created inconsistent scenarios nor every element on screen always had a `testID` available. + + *sidenote: `iOSLabel` and `androidWidget` are utility functions created while working on [the first PR](https://github.com/facebook/react-native/pull/36267). More utility functions to further simply writing tests can be added as work progresses.* + - `specs` -> this folder follows a similar 1:1 mapping to the RNTester screens, but for the tests: for each screen (or subscreen) there's a dedicated `*.test.js` file (such as `buttonComponentScreen.test.js`). Ideally, in this file the Jest tests are standard, leveraging the `*.screen.js` counterpart for the details of defining how Appium/WDIO can reach those elements on screen. - `helpers` -> where utility code, such as methods for checking element existence, clicking interaction, etc. will live @@ -113,7 +126,7 @@ The current roadmap is as follows: Because this proposal doesn't directly affect consumers of React Native, the need for "teaching content" is scoped to people who wants to learn more about this infrastructure is set up and they want to contribute with more tests. -The first place where this type of documentation will be added is the readme of the dedicated new folder, `packages/rn-tester-e2e/README.md` _(you can already check out a draft of it [in the first PR](https://github.com/mateuszm22/react-native/blob/k+m/new-rn-tester-E2E/packages/rn-tester-e2e/README.md) already in the works)_. In this file, there are going to be information on how the setup works, how to test it locally and how to add new tests. +The first place where this type of documentation will be added is the readme of the dedicated new folder, `packages/rn-tester-e2e/README.md` *(you can already check out a draft of it [in the first PR](https://github.com/mateuszm22/react-native/blob/k+m/new-rn-tester-E2E/packages/rn-tester-e2e/README.md) already in the works)*. In this file, there are going to be information on how the setup works, how to test it locally and how to add new tests. Building on top of that, an umbrella issue will be created to coordinate and provide actionable examples for how to add new tests. In it, a streamlined explanation will be provided that will then reference back to the dedicated `packages/rn-tester-e2e/README.md`. From 8998abf6f3d835506669d9172b83b68de8bb5d93 Mon Sep 17 00:00:00 2001 From: Lorenzo Sciandra Date: Fri, 21 Jul 2023 15:52:32 +0100 Subject: [PATCH 07/10] graph tweak --- proposals/0684-adding-e2e-in-core.md | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/proposals/0684-adding-e2e-in-core.md b/proposals/0684-adding-e2e-in-core.md index cc26de7e..94a10a29 100644 --- a/proposals/0684-adding-e2e-in-core.md +++ b/proposals/0684-adding-e2e-in-core.md @@ -60,13 +60,11 @@ The dedicated code configuring the tooling and the tests will be in its own priv In it, the `tests` folder is where the tests and referencing files all live. The substructure is as follows: - ```md - rn-tester-e2e - └──tests - ├── screens - ├── specs - └── helpers - ``` + rn-tester-e2e + └──tests + ├── screens + ├── specs + └── helpers - `screens` -> in this folder, you will find `*.screen.js` files, where each file represents a navigation screen for RNTester. So there are 3 root ones (`apis`, `bookmarks`, `components`) and then for subscreens, there's a folder with the same name. Each of these files provide an easy way to define all elements present in said screen, so that they can be used for tests. - for each element of a given screen there will be a platform-specific reference in the form of From d9e6db020f5ac95919e9c510492776d49cb89236 Mon Sep 17 00:00:00 2001 From: Lorenzo Sciandra Date: Wed, 26 Jul 2023 10:48:13 +0100 Subject: [PATCH 08/10] Update proposals/0684-adding-e2e-in-core.md Co-authored-by: Nicola Corti --- proposals/0684-adding-e2e-in-core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/0684-adding-e2e-in-core.md b/proposals/0684-adding-e2e-in-core.md index 94a10a29..12fc1d69 100644 --- a/proposals/0684-adding-e2e-in-core.md +++ b/proposals/0684-adding-e2e-in-core.md @@ -28,7 +28,7 @@ This will make the codebase more stable, surface issues rapidly to the commit au ## Basic example -On a basic level, the idea is to have fully automated end-to-end testing running on CircleCI on `react-native`'s every single commit to flag if any code change is inadvertently introducing a regression of some form. +On a basic level, the idea is to have fully automated end-to-end testing running on CircleCI on `react-native`'s to flag if any code change is inadvertently introducing a regression of some form. The code and tests to do so will live in a new dedicated monorepo package, `packages/rn-tester-e2e` and rely on the existing `RNTester` test app. From 490b3840ebdeda92fe6f1da234e75dd8915dbeda Mon Sep 17 00:00:00 2001 From: Lorenzo Sciandra Date: Wed, 26 Jul 2023 10:48:38 +0100 Subject: [PATCH 09/10] Update proposals/0684-adding-e2e-in-core.md --- proposals/0684-adding-e2e-in-core.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/proposals/0684-adding-e2e-in-core.md b/proposals/0684-adding-e2e-in-core.md index 12fc1d69..915cca83 100644 --- a/proposals/0684-adding-e2e-in-core.md +++ b/proposals/0684-adding-e2e-in-core.md @@ -130,6 +130,3 @@ Building on top of that, an umbrella issue will be created to coordinate and pro And, of course, we can also point people to this RFC for more context/historical details. -## Unresolved questions - -This proposal lives in a bit of a peculiar state because it's been written 6 months after the core investigation and decision have been taken - so there isn't much unresolved at this point. Leaving this phrase here anyway in case on the RFC someone wants to add something. From 760c4e0871afa805c66907457858e92dfa312dd1 Mon Sep 17 00:00:00 2001 From: Lorenzo Sciandra Date: Wed, 2 Aug 2023 13:27:27 +0100 Subject: [PATCH 10/10] Update proposals/0684-adding-e2e-in-core.md Co-authored-by: Szymon Rybczak --- proposals/0684-adding-e2e-in-core.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/proposals/0684-adding-e2e-in-core.md b/proposals/0684-adding-e2e-in-core.md index 915cca83..8f2dde6c 100644 --- a/proposals/0684-adding-e2e-in-core.md +++ b/proposals/0684-adding-e2e-in-core.md @@ -4,7 +4,12 @@ author: - Lorenzo Sciandra - Nicola Corti - Riccardo Cipolleschi - - + - Mateusz Ulańczyk + - Adrian Orszulik + - Mateusz Michalec + - Elżbieta Berger + - Michał Pierzchała + - Szymon Rybczak date: 2023-07-06 ---