From 0d6c5378ea9c0d892a7fa24e6981be7944844b14 Mon Sep 17 00:00:00 2001 From: Yande Date: Tue, 15 Oct 2024 15:30:55 +0100 Subject: [PATCH 1/9] Create mobile-e2e-mocking.md --- docs/testing/e2e/mobile-e2e-mocking.md | 32 ++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 docs/testing/e2e/mobile-e2e-mocking.md diff --git a/docs/testing/e2e/mobile-e2e-mocking.md b/docs/testing/e2e/mobile-e2e-mocking.md new file mode 100644 index 0000000..642fb29 --- /dev/null +++ b/docs/testing/e2e/mobile-e2e-mocking.md @@ -0,0 +1,32 @@ +# Mocking Endpoints with E2E Testing + +## Mocking + +Mocking is an important technique we use in our testing strategy to simulate various scenarios and conditions that our application may encounter. By creating mock responses for our API endpoints, we can effectively test how the app behaves under specific circumstances, such as network failures or receiving unexpected data. + +We believe that mocking should complement our end-to-end (E2E) testing rather than replace it. While E2E tests provide vital confidence in the overall functionality of the MetaMask app, mocking allows us to conduct more focused component tests. This helps us identify issues early in the development process and ensures our app can handle different states gracefully. + +That said, we still believe E2E tests should be carried out wherever possible to ensure that the application behaves as intended for its end users. + +As we identify and add more mocked tests, the implementation of our mocking strategy will evolve. This flexibility ensures that our testing remains relevant and effective as the application grows. + +## File Structure + +To maintain a clear and organised structure, we have separated our E2E tests from our mocked tests. This distinction helps us manage our testing efforts more effectively. + +```plaintext +root/ +├── e2e/ +│ ├── spec/ +│ │ ├── Accounts/ +│ │ │ └── spec.js +│ │ └── Transactions/ +│ │ └── spec.js +└── mocks/ + ├── Accounts/ + │ └── mockSpec.js + └── Transactions/ + └── mockSpec.js +This structure allows us to keep our E2E tests focused on overall app functionality while utilising mocks to simulate various conditions. + +By adopting this approach, we ensure our tests remain robust and relevant as we continue to enhance the MetaMask application. \ No newline at end of file From 287f34590624b7165a4918936ff7a3ecfc684dde Mon Sep 17 00:00:00 2001 From: Yande Date: Mon, 21 Oct 2024 23:15:32 +0100 Subject: [PATCH 2/9] final mocking doc --- docs/testing/e2e/mobile-e2e-mocking.md | 125 +++++++++++++++++++++---- 1 file changed, 108 insertions(+), 17 deletions(-) diff --git a/docs/testing/e2e/mobile-e2e-mocking.md b/docs/testing/e2e/mobile-e2e-mocking.md index 642fb29..1b3ef97 100644 --- a/docs/testing/e2e/mobile-e2e-mocking.md +++ b/docs/testing/e2e/mobile-e2e-mocking.md @@ -1,18 +1,16 @@ -# Mocking Endpoints with E2E Testing +# Mocking APIs in MetaMask Mobile for Enhanced E2E Testing ## Mocking -Mocking is an important technique we use in our testing strategy to simulate various scenarios and conditions that our application may encounter. By creating mock responses for our API endpoints, we can effectively test how the app behaves under specific circumstances, such as network failures or receiving unexpected data. +Mocking is an essential technique in our testing strategy, allowing us to simulate various conditions the application may encounter. By creating mock responses for API endpoints, we can effectively test how the app behaves in scenarios like network failures or receiving unexpected data. -We believe that mocking should complement our end-to-end (E2E) testing rather than replace it. While E2E tests provide vital confidence in the overall functionality of the MetaMask app, mocking allows us to conduct more focused component tests. This helps us identify issues early in the development process and ensures our app can handle different states gracefully. +We view mocking as a complement to, not a replacement for, end-to-end (E2E) testing. While E2E tests provide confidence in the overall functionality of the MetaMask app, mocking enables focused component tests that help identify issues early in development. This ensures the app can handle different states gracefully. -That said, we still believe E2E tests should be carried out wherever possible to ensure that the application behaves as intended for its end users. - -As we identify and add more mocked tests, the implementation of our mocking strategy will evolve. This flexibility ensures that our testing remains relevant and effective as the application grows. +E2E tests should be used wherever possible to validate the application for its end users, while mocking fills gaps where E2E tests may be unreliable or difficult to set up. As more mocked tests are added, our implementation strategy will evolve, keeping testing relevant and effective. ## File Structure -To maintain a clear and organised structure, we have separated our E2E tests from our mocked tests. This distinction helps us manage our testing efforts more effectively. +We maintain a clear and organised structure to separate E2E tests from mocked tests, which helps manage our testing efforts effectively. ```plaintext root/ @@ -20,13 +18,106 @@ root/ │ ├── spec/ │ │ ├── Accounts/ │ │ │ └── spec.js -│ │ └── Transactions/ -│ │ └── spec.js -└── mocks/ - ├── Accounts/ - │ └── mockSpec.js - └── Transactions/ - └── mockSpec.js -This structure allows us to keep our E2E tests focused on overall app functionality while utilising mocks to simulate various conditions. - -By adopting this approach, we ensure our tests remain robust and relevant as we continue to enhance the MetaMask application. \ No newline at end of file +│ │ ├── Transactions/ +│ │ │ └── spec.js +│ ├── mocked-specs/ +│ │ ├── Accounts/ +│ │ │ └── mockSpec.js +│ │ ├── Transactions/ +│ │ └── mockSpec.js +``` + +This structure allows us to keep E2E tests focused on overall app functionality while leveraging mocks to simulate various conditions. + +## Mock Server Implementation Guide + +### Overview + +This guide outlines how to implement API request mocking using Mockttp for mobile testing. Mocking lets you simulate API responses and handle both GET and POST requests during testing, ensuring the app behaves correctly even when external dependencies are unavailable or unreliable. + +### Key Features + +- Handles both GET and POST requests. +- Configurable requests and responses through events, allowing flexibility in response statuses and request bodies. +- Logs responses for easier debugging during tests. + +### Setting Up the Mock Server + +To start the mock server, use the `startMockServer` function from `e2e/mockServer/mockServer.js`. This function accepts events organised by HTTP methods (GET, POST), specifying the endpoint, the response to return, and the request body for POST requests. + +```javascript +import { mockEvents } from '../mockServer/mock-config/mock-events'; + +mockServer = await startMockServer({ + GET: [ + mockEvents.GET.suggestedGasApiErrorResponse, + ], + POST: [ + mockEvents.POST.suggestedGasApiPostResponse, + ], +}); +``` + +This starts the mock server and ensures it listens for the defined routes, returning the specified responses. + +### Defining Mock Events + +Mock events are defined in the `e2e/mockServer/mock-config/mock-events.js` file. Each key represents an HTTP method, and events include: + +- **urlEndpoint**: The API endpoint being mocked. +- **response**: The mock response the server will return. +- **requestBody**: (For POST requests) The expected request body. + +```javascript +export const mockEvents = { + GET: { + suggestedGasApiErrorResponse: { + urlEndpoint: 'https://gas.api.cx.metamask.io/networks/1/suggestedGasFees', + response: { status: 500, message: 'Internal Server Error' }, + }, + }, + POST: { + suggestedGasApiPostResponse: { + urlEndpoint: 'https://gas.api.cx.metamask.io/networks/1/suggestedGasFees', + response: { status: 200, message: 'Success' }, + requestBody: { priorityFee: '2', maxFee: '2.000855333' }, + }, + }, +}; +``` + +The mock responses are stored in `e2e/mockServer/mock-responses/mockResponses.js`, keeping the responses modular and reusable. + +### Naming Test Files + +Mock test files should include `.mock.spec.js` in their filename for clarity and organisation. For example, tests for the suggested gas API would be named: + +``` +suggestedGasApi.mock.spec.js +``` + +This naming convention makes it easy to distinguish mock tests from E2E tests, maintaining a clean and organised test suite. + +### Logging + +The mock server logs the response status and body to help track what’s being mocked, making debugging simpler. + +### Strategy for Using Mock Testing + +Mock testing should complement E2E testing. The aim is to use E2E tests to gain confidence in the app's functionality wherever possible. However, mock testing can be used to fill gaps in scenarios where E2E tests may be unreliable or challenging, such as: + +- Testing components under specific network conditions. +- Ensuring consistent behaviour across mobile platforms. +- Simulating server errors or slow responses. + +By blending E2E and mock testing, we ensure comprehensive test coverage while maintaining fast and reliable tests that simulate real-world conditions. + +## File Structure + +Here’s an example of how your files should be structured: + +- `e2e/mockServer/mockServer.js`: The main file where the mock server is started. +- `e2e/mockServer/mock-config/mock-events.js`: Defines mock events (GET and POST) and their associated endpoints and responses. +- `e2e/mockServer/mock-responses/mockResponses.js`: Contains the mock responses used by the mock events. + +Following this structure and strategy ensures efficient mock testing, complementing your E2E tests. From 69e0395964448e3c2006004af5eb2ab69c3927b4 Mon Sep 17 00:00:00 2001 From: Yande Date: Mon, 21 Oct 2024 23:31:26 +0100 Subject: [PATCH 3/9] when to use mocks --- docs/testing/e2e/mobile-e2e-mocking.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/docs/testing/e2e/mobile-e2e-mocking.md b/docs/testing/e2e/mobile-e2e-mocking.md index 1b3ef97..1b98c98 100644 --- a/docs/testing/e2e/mobile-e2e-mocking.md +++ b/docs/testing/e2e/mobile-e2e-mocking.md @@ -112,6 +112,14 @@ Mock testing should complement E2E testing. The aim is to use E2E tests to gain By blending E2E and mock testing, we ensure comprehensive test coverage while maintaining fast and reliable tests that simulate real-world conditions. +## When to Use Mocks + +You should use mocks in scenarios such as testing isolated features without relying on live data or real backend services. This includes testing edge cases that are difficult to reproduce with real data or ensuring deterministic test results by controlling the inputs and outputs. For example, when the `suggestedGasApi` is down, the app should default to the legacy modal and API. This is a scenario that cannot be consistently tested with E2E or even manually. Mocking enables us to test the app's behaviour in isolated scenarios or edge cases that are difficult to reproduce efficiently in E2E or manual testing. + +## When Not to Use Mocks + +Be cautious against overusing mocks, especially when integration with real services is essential for accurate testing. Relying too heavily on mocks could result in tests that do not reflect real-world conditions, leading to false confidence in system stability. + ## File Structure Here’s an example of how your files should be structured: From 727fe2baf514623468aa48e248e1cc5d0f0ea959 Mon Sep 17 00:00:00 2001 From: Yande Date: Mon, 21 Oct 2024 23:38:26 +0100 Subject: [PATCH 4/9] minor changes --- docs/testing/e2e/mobile-e2e-mocking.md | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/docs/testing/e2e/mobile-e2e-mocking.md b/docs/testing/e2e/mobile-e2e-mocking.md index 1b98c98..7e9d325 100644 --- a/docs/testing/e2e/mobile-e2e-mocking.md +++ b/docs/testing/e2e/mobile-e2e-mocking.md @@ -119,13 +119,3 @@ You should use mocks in scenarios such as testing isolated features without rely ## When Not to Use Mocks Be cautious against overusing mocks, especially when integration with real services is essential for accurate testing. Relying too heavily on mocks could result in tests that do not reflect real-world conditions, leading to false confidence in system stability. - -## File Structure - -Here’s an example of how your files should be structured: - -- `e2e/mockServer/mockServer.js`: The main file where the mock server is started. -- `e2e/mockServer/mock-config/mock-events.js`: Defines mock events (GET and POST) and their associated endpoints and responses. -- `e2e/mockServer/mock-responses/mockResponses.js`: Contains the mock responses used by the mock events. - -Following this structure and strategy ensures efficient mock testing, complementing your E2E tests. From b14afe5cbe9689f0b7447ddda6e494cb29a39fbb Mon Sep 17 00:00:00 2001 From: Yande Date: Fri, 25 Oct 2024 01:06:15 +0200 Subject: [PATCH 5/9] Final doc --- docs/testing/e2e/mobile-e2e-mocking.md | 39 ++++++++++++++++++++++++-- 1 file changed, 37 insertions(+), 2 deletions(-) diff --git a/docs/testing/e2e/mobile-e2e-mocking.md b/docs/testing/e2e/mobile-e2e-mocking.md index 7e9d325..457e630 100644 --- a/docs/testing/e2e/mobile-e2e-mocking.md +++ b/docs/testing/e2e/mobile-e2e-mocking.md @@ -1,3 +1,4 @@ + # Mocking APIs in MetaMask Mobile for Enhanced E2E Testing ## Mocking @@ -25,6 +26,9 @@ root/ │ │ │ └── mockSpec.js │ │ ├── Transactions/ │ │ └── mockSpec.js + mockServer/ +│ ├── mock-responses/ +│ │ └── mockResponses.json ``` This structure allows us to keep E2E tests focused on overall app functionality while leveraging mocks to simulate various conditions. @@ -43,7 +47,7 @@ This guide outlines how to implement API request mocking using Mockttp for mobil ### Setting Up the Mock Server -To start the mock server, use the `startMockServer` function from `e2e/mockServer/mockServer.js`. This function accepts events organised by HTTP methods (GET, POST), specifying the endpoint, the response to return, and the request body for POST requests. +To start the mock server, use the `startMockServer` function from `e2e/mockServer/mockServer.js`. This function accepts events organised by HTTP methods (GET, POST), specifying the endpoint, the response to return, and the request body for POST requests. The function enables us to pass multiple events enabling us to mock multiple services at once ```javascript import { mockEvents } from '../mockServer/mock-config/mock-events'; @@ -86,7 +90,38 @@ export const mockEvents = { }; ``` -The mock responses are stored in `e2e/mockServer/mock-responses/mockResponses.js`, keeping the responses modular and reusable. +The mock responses are stored in a separate JSON file `mockResponses.json`, located in `e2e/mockServer/mock-responses/`, keeping the responses modular and reusable. + +### Response Structure in `mockResponses.json` + +Mock responses are organised with identifiable keys for ease of use. Each key corresponds to a specific API, and subkeys can be used to organise different types of responses, such as success or error scenarios. + +```json +{ + "suggestedGasApiResponses": { + "success": { + "low": { + "suggestedMaxFeePerGas": "1.000503137", + "waitTime": 15000 + }, + "medium": { + "suggestedMaxFeePerGas": "1.500679235", + "waitTime": 15000 + }, + "high": { + "suggestedMaxFeePerGas": "2.000855333", + "waitTime": 15000 + } + }, + "error": { + "status": 500, + "message": "Internal Server Error" + } + } +} +``` + +This structure allows for easy identification and access to various response types for the same API. For example, you can mock success and error responses for the `suggestedGasApi` by referencing `suggestedGasApiResponses.success` or `suggestedGasApiResponses.error` in your test cases. ### Naming Test Files From 61c84c337e65903bef493dfb4c57eb90849b6a09 Mon Sep 17 00:00:00 2001 From: Yande Date: Mon, 28 Oct 2024 17:53:06 +0000 Subject: [PATCH 6/9] small alterations --- docs/testing/e2e/mobile-e2e-mocking.md | 35 +++++++++++++++----------- 1 file changed, 20 insertions(+), 15 deletions(-) diff --git a/docs/testing/e2e/mobile-e2e-mocking.md b/docs/testing/e2e/mobile-e2e-mocking.md index 457e630..2deaf5c 100644 --- a/docs/testing/e2e/mobile-e2e-mocking.md +++ b/docs/testing/e2e/mobile-e2e-mocking.md @@ -11,7 +11,8 @@ E2E tests should be used wherever possible to validate the application for its e ## File Structure -We maintain a clear and organised structure to separate E2E tests from mocked tests, which helps manage our testing efforts effectively. +To identify mocked tests, we rely on naming conventions for now. We maintain a clear and organised structure to separate E2E tests from mocked tests, which helps manage our testing efforts effectively. + ```plaintext root/ @@ -19,38 +20,38 @@ root/ │ ├── spec/ │ │ ├── Accounts/ │ │ │ └── spec.js + mock.spec.js │ │ ├── Transactions/ │ │ │ └── spec.js -│ ├── mocked-specs/ -│ │ ├── Accounts/ -│ │ │ └── mockSpec.js -│ │ ├── Transactions/ -│ │ └── mockSpec.js - mockServer/ -│ ├── mock-responses/ -│ │ └── mockResponses.json + mock.spec.js +│ ├── api-mocking/ +│ ├── api-mocking/ +│ │ ├── mock-responses/ +│ │ │ ├── gas-api-responses.json ``` + This structure allows us to keep E2E tests focused on overall app functionality while leveraging mocks to simulate various conditions. + ## Mock Server Implementation Guide ### Overview -This guide outlines how to implement API request mocking using Mockttp for mobile testing. Mocking lets you simulate API responses and handle both GET and POST requests during testing, ensuring the app behaves correctly even when external dependencies are unavailable or unreliable. +This guide outlines how to implement API request mocking using Mockttp for mobile testing. Mocking lets you simulate API responses and handle any HTTP method required during testing, ensuring the app behaves correctly even when external dependencies are unavailable or unreliable. ### Key Features -- Handles both GET and POST requests. +- Handles multiple HTTP methods as required by teams. - Configurable requests and responses through events, allowing flexibility in response statuses and request bodies. - Logs responses for easier debugging during tests. ### Setting Up the Mock Server -To start the mock server, use the `startMockServer` function from `e2e/mockServer/mockServer.js`. This function accepts events organised by HTTP methods (GET, POST), specifying the endpoint, the response to return, and the request body for POST requests. The function enables us to pass multiple events enabling us to mock multiple services at once +To start the mock server, use the `startMockServer` function from `e2e/api-mocking/mock-server.js`. This function accepts events organised by HTTP methods (e.g., GET, POST), specifying the endpoint, the response to return, and the request body for POST requests. The function enables us to pass multiple events enabling us to mock multiple services at once ```javascript -import { mockEvents } from '../mockServer/mock-config/mock-events'; +import { mockEvents } from '../api-mocking/mock-config/mock-events'; mockServer = await startMockServer({ GET: [ @@ -66,7 +67,7 @@ This starts the mock server and ensures it listens for the defined routes, retur ### Defining Mock Events -Mock events are defined in the `e2e/mockServer/mock-config/mock-events.js` file. Each key represents an HTTP method, and events include: +Mock events are defined in the `e2e/api-mocking/mock-config/mock-events.js` file. Each key represents an HTTP method, and events include: - **urlEndpoint**: The API endpoint being mocked. - **response**: The mock response the server will return. @@ -90,7 +91,7 @@ export const mockEvents = { }; ``` -The mock responses are stored in a separate JSON file `mockResponses.json`, located in `e2e/mockServer/mock-responses/`, keeping the responses modular and reusable. +The mock responses are stored in a separate JSON file `mockResponses.json`, located in `e2e/api-mocking/mock-responses/`, keeping the responses modular and reusable. ### Response Structure in `mockResponses.json` @@ -154,3 +155,7 @@ You should use mocks in scenarios such as testing isolated features without rely ## When Not to Use Mocks Be cautious against overusing mocks, especially when integration with real services is essential for accurate testing. Relying too heavily on mocks could result in tests that do not reflect real-world conditions, leading to false confidence in system stability. + +## Exception for Complex Mock Events + +Teams with complex mock events or criteria can utilise the `mockspecificTest` attribute, where you can define custom mock events in a separate instance to fit your unique requirements. This can be liased with the mobile QA platform team. From 187852f8e4efbaa75dd8015734fe6327d16d4c64 Mon Sep 17 00:00:00 2001 From: Yande Date: Mon, 28 Oct 2024 19:11:54 +0000 Subject: [PATCH 7/9] small change --- docs/testing/e2e/mobile-e2e-mocking.md | 70 ++++++++++++++++---------- 1 file changed, 43 insertions(+), 27 deletions(-) diff --git a/docs/testing/e2e/mobile-e2e-mocking.md b/docs/testing/e2e/mobile-e2e-mocking.md index 2deaf5c..f6dfae9 100644 --- a/docs/testing/e2e/mobile-e2e-mocking.md +++ b/docs/testing/e2e/mobile-e2e-mocking.md @@ -46,6 +46,16 @@ This guide outlines how to implement API request mocking using Mockttp for mobil - Configurable requests and responses through events, allowing flexibility in response statuses and request bodies. - Logs responses for easier debugging during tests. +### Naming Test Files + +Mock test files should include `.mock.spec.js` in their filename for clarity and organisation. For example, tests for the suggested gas API would be named: + +``` +suggestedGasApi.mock.spec.js +``` + +This naming convention makes it easy to distinguish mock tests from E2E tests, maintaining a clean and organised test suite. + ### Setting Up the Mock Server To start the mock server, use the `startMockServer` function from `e2e/api-mocking/mock-server.js`. This function accepts events organised by HTTP methods (e.g., GET, POST), specifying the endpoint, the response to return, and the request body for POST requests. The function enables us to pass multiple events enabling us to mock multiple services at once @@ -95,44 +105,50 @@ The mock responses are stored in a separate JSON file `mockResponses.json`, loca ### Response Structure in `mockResponses.json` -Mock responses are organised with identifiable keys for ease of use. Each key corresponds to a specific API, and subkeys can be used to organise different types of responses, such as success or error scenarios. +# Mock Response Structure + +Mock responses are now organised into individual JSON files for each related API or service, simplifying access and maintenance. Each file contains identifiable keys specific to the API, with subkeys as needed to structure various response scenarios, such as suggestedGasApiResponses or suggestedGasFeesApiGanache. + +### Example: `gas-api-responses.json` ```json { "suggestedGasApiResponses": { - "success": { - "low": { - "suggestedMaxFeePerGas": "1.000503137", - "waitTime": 15000 - }, - "medium": { - "suggestedMaxFeePerGas": "1.500679235", - "waitTime": 15000 - }, - "high": { - "suggestedMaxFeePerGas": "2.000855333", - "waitTime": 15000 - } - }, "error": { - "status": 500, "message": "Internal Server Error" } + }, + "suggestedGasFeesApiGanache": { + "low": { + "suggestedMaxPriorityFeePerGas": "1", + "suggestedMaxFeePerGas": "1.000503137", + "minWaitTimeEstimate": 15000, + "maxWaitTimeEstimate": 60000 + }, + "medium": { + "suggestedMaxPriorityFeePerGas": "1.5", + "suggestedMaxFeePerGas": "1.500679235", + "minWaitTimeEstimate": 15000, + "maxWaitTimeEstimate": 45000 + }, + "high": { + "suggestedMaxPriorityFeePerGas": "2", + "suggestedMaxFeePerGas": "2.000855333", + "minWaitTimeEstimate": 15000, + "maxWaitTimeEstimate": 30000 + }, + "estimatedBaseFee": "0.000503137", + "networkCongestion": 0.34, + "latestPriorityFeeRange": ["1.5", "2"], + "historicalPriorityFeeRange": ["0.000001", "236.428872442"], + "historicalBaseFeeRange": ["0.000392779", "0.00100495"], + "priorityFeeTrend": "up", + "baseFeeTrend": "up", + "version": "0.0.1" } } -``` -This structure allows for easy identification and access to various response types for the same API. For example, you can mock success and error responses for the `suggestedGasApi` by referencing `suggestedGasApiResponses.success` or `suggestedGasApiResponses.error` in your test cases. -### Naming Test Files - -Mock test files should include `.mock.spec.js` in their filename for clarity and organisation. For example, tests for the suggested gas API would be named: - -``` -suggestedGasApi.mock.spec.js -``` - -This naming convention makes it easy to distinguish mock tests from E2E tests, maintaining a clean and organised test suite. ### Logging From e946bb4dc606775dcd4c818a9f88244b84ed1208 Mon Sep 17 00:00:00 2001 From: Yande Date: Mon, 28 Oct 2024 20:03:47 +0000 Subject: [PATCH 8/9] streamlined doc --- docs/testing/e2e/mobile-e2e-mocking.md | 136 +++++++++---------------- 1 file changed, 47 insertions(+), 89 deletions(-) diff --git a/docs/testing/e2e/mobile-e2e-mocking.md b/docs/testing/e2e/mobile-e2e-mocking.md index f6dfae9..1f6f906 100644 --- a/docs/testing/e2e/mobile-e2e-mocking.md +++ b/docs/testing/e2e/mobile-e2e-mocking.md @@ -1,18 +1,19 @@ # Mocking APIs in MetaMask Mobile for Enhanced E2E Testing -## Mocking +## Introduction +This document outlines how MetaMask Mobile uses API mocking to boost End-to-End (E2E) testing. Mocking lets us simulate different conditions that the app might face, ensuring it functions reliably across various scenarios. -Mocking is an essential technique in our testing strategy, allowing us to simulate various conditions the application may encounter. By creating mock responses for API endpoints, we can effectively test how the app behaves in scenarios like network failures or receiving unexpected data. +## Mocking vs. E2E Testing +While E2E tests verify the overall user experience, mocking focuses on testing individual components. Here’s how they differ: -We view mocking as a complement to, not a replacement for, end-to-end (E2E) testing. While E2E tests provide confidence in the overall functionality of the MetaMask app, mocking enables focused component tests that help identify issues early in development. This ensures the app can handle different states gracefully. +- **E2E Tests**: These validate the app's functionality as a whole, interacting with real APIs and backend services. +- **Mocking**: Simulates responses from APIs, allowing us to test components in specific network conditions or edge cases. -E2E tests should be used wherever possible to validate the application for its end users, while mocking fills gaps where E2E tests may be unreliable or difficult to set up. As more mocked tests are added, our implementation strategy will evolve, keeping testing relevant and effective. +We use mocking to enhance our E2E testing, especially for scenarios where E2E alone might be unreliable or tricky to set up. ## File Structure - -To identify mocked tests, we rely on naming conventions for now. We maintain a clear and organised structure to separate E2E tests from mocked tests, which helps manage our testing efforts effectively. - +We keep E2E and mock tests separate with file naming conventions: ```plaintext root/ @@ -20,10 +21,10 @@ root/ │ ├── spec/ │ │ ├── Accounts/ │ │ │ └── spec.js - mock.spec.js + mock.spec.js# Mock test for Accounts │ │ ├── Transactions/ │ │ │ └── spec.js - mock.spec.js + mock.spec.js # Mock test for Transactions │ ├── api-mocking/ │ ├── api-mocking/ │ │ ├── mock-responses/ @@ -31,34 +32,25 @@ root/ ``` -This structure allows us to keep E2E tests focused on overall app functionality while leveraging mocks to simulate various conditions. +This structure promotes clear organisation and makes managing tests simpler. - -## Mock Server Implementation Guide +## Mock Server Implementation ### Overview - -This guide outlines how to implement API request mocking using Mockttp for mobile testing. Mocking lets you simulate API responses and handle any HTTP method required during testing, ensuring the app behaves correctly even when external dependencies are unavailable or unreliable. +We use Mockttp to simulate API responses, providing flexible testing across different HTTP methods. This allows us to test app behaviour even when external dependencies are unavailable or unreliable. ### Key Features +- Supports multiple HTTP methods (GET, POST, etc.) +- Configurable requests and responses +- Logs responses to simplify debugging -- Handles multiple HTTP methods as required by teams. -- Configurable requests and responses through events, allowing flexibility in response statuses and request bodies. -- Logs responses for easier debugging during tests. +### Naming Mock Test Files +Mock test files are named with `.mock.spec.js` to keep things organised. For example, a test for the suggested gas API would be named: -### Naming Test Files - -Mock test files should include `.mock.spec.js` in their filename for clarity and organisation. For example, tests for the suggested gas API would be named: - -``` -suggestedGasApi.mock.spec.js -``` - -This naming convention makes it easy to distinguish mock tests from E2E tests, maintaining a clean and organised test suite. +`suggestedGasApi.mock.spec.js` ### Setting Up the Mock Server - -To start the mock server, use the `startMockServer` function from `e2e/api-mocking/mock-server.js`. This function accepts events organised by HTTP methods (e.g., GET, POST), specifying the endpoint, the response to return, and the request body for POST requests. The function enables us to pass multiple events enabling us to mock multiple services at once +The `startMockServer` function in `e2e/api-mocking/mock-server.js` starts the mock server. It takes events organised by HTTP methods, specifying the endpoint, response data, and request body (for POST requests). ```javascript import { mockEvents } from '../api-mocking/mock-config/mock-events'; @@ -73,15 +65,12 @@ mockServer = await startMockServer({ }); ``` -This starts the mock server and ensures it listens for the defined routes, returning the specified responses. - ### Defining Mock Events +`mockEvents.js` defines mock events, including: -Mock events are defined in the `e2e/api-mocking/mock-config/mock-events.js` file. Each key represents an HTTP method, and events include: - -- **urlEndpoint**: The API endpoint being mocked. -- **response**: The mock response the server will return. -- **requestBody**: (For POST requests) The expected request body. +- `urlEndpoint`: The API endpoint being mocked +- `response`: The mock response the server will return +- `requestBody`: Expected request body (for POST requests) ```javascript export const mockEvents = { @@ -101,15 +90,12 @@ export const mockEvents = { }; ``` -The mock responses are stored in a separate JSON file `mockResponses.json`, located in `e2e/api-mocking/mock-responses/`, keeping the responses modular and reusable. - -### Response Structure in `mockResponses.json` +Mock responses are saved in separate JSON files (`mockResponses.json`) for reusability and easier management. -# Mock Response Structure +### Response Structure +Mock responses are stored in individual JSON files for each API or service, making them easier to maintain. Each file contains keys for the API and subkeys for various scenarios. -Mock responses are now organised into individual JSON files for each related API or service, simplifying access and maintenance. Each file contains identifiable keys specific to the API, with subkeys as needed to structure various response scenarios, such as suggestedGasApiResponses or suggestedGasFeesApiGanache. - -### Example: `gas-api-responses.json` +**Example:** `gas-api-responses.json` ```json { @@ -119,59 +105,31 @@ Mock responses are now organised into individual JSON files for each related API } }, "suggestedGasFeesApiGanache": { - "low": { - "suggestedMaxPriorityFeePerGas": "1", - "suggestedMaxFeePerGas": "1.000503137", - "minWaitTimeEstimate": 15000, - "maxWaitTimeEstimate": 60000 - }, - "medium": { - "suggestedMaxPriorityFeePerGas": "1.5", - "suggestedMaxFeePerGas": "1.500679235", - "minWaitTimeEstimate": 15000, - "maxWaitTimeEstimate": 45000 - }, - "high": { - "suggestedMaxPriorityFeePerGas": "2", - "suggestedMaxFeePerGas": "2.000855333", - "minWaitTimeEstimate": 15000, - "maxWaitTimeEstimate": 30000 - }, - "estimatedBaseFee": "0.000503137", - "networkCongestion": 0.34, - "latestPriorityFeeRange": ["1.5", "2"], - "historicalPriorityFeeRange": ["0.000001", "236.428872442"], - "historicalBaseFeeRange": ["0.000392779", "0.00100495"], - "priorityFeeTrend": "up", - "baseFeeTrend": "up", - "version": "0.0.1" + # ... detailed gas fee data ... } } +``` +## Logging +The mock server logs response statuses and bodies to help track mocked requests, making debugging more straightforward. +## Using Mock Testing Effectively +Mock testing should work hand-in-hand with E2E testing. Here’s some guidance: -### Logging - -The mock server logs the response status and body to help track what’s being mocked, making debugging simpler. - -### Strategy for Using Mock Testing - -Mock testing should complement E2E testing. The aim is to use E2E tests to gain confidence in the app's functionality wherever possible. However, mock testing can be used to fill gaps in scenarios where E2E tests may be unreliable or challenging, such as: - -- Testing components under specific network conditions. -- Ensuring consistent behaviour across mobile platforms. -- Simulating server errors or slow responses. - -By blending E2E and mock testing, we ensure comprehensive test coverage while maintaining fast and reliable tests that simulate real-world conditions. - -## When to Use Mocks - -You should use mocks in scenarios such as testing isolated features without relying on live data or real backend services. This includes testing edge cases that are difficult to reproduce with real data or ensuring deterministic test results by controlling the inputs and outputs. For example, when the `suggestedGasApi` is down, the app should default to the legacy modal and API. This is a scenario that cannot be consistently tested with E2E or even manually. Mocking enables us to test the app's behaviour in isolated scenarios or edge cases that are difficult to reproduce efficiently in E2E or manual testing. +### When to Use Mocks: +- For testing isolated features without relying on live data +- For testing edge cases that are tricky to reproduce with real data +- For deterministic test results by controlling inputs and outputs -## When Not to Use Mocks +### When Not to Use Mocks: +- Overusing mocks may result in tests that don’t reflect real-world conditions. +- Integration with live services is essential for accurate testing. -Be cautious against overusing mocks, especially when integration with real services is essential for accurate testing. Relying too heavily on mocks could result in tests that do not reflect real-world conditions, leading to false confidence in system stability. +### Exception for Complex Mock Events +For more complex mock events or criteria, you can use the `mockspecificTest` attribute to define custom mock events. -## Exception for Complex Mock Events +### Current Workaround for Network Request Interception +Due to limitations in intercepting network requests directly, we currently route traffic through a proxy server. This lets us intercept and mock requests as needed. -Teams with complex mock events or criteria can utilise the `mockspecificTest` attribute, where you can define custom mock events in a separate instance to fit your unique requirements. This can be liased with the mobile QA platform team. +## Future Improvements +We’re looking into further enhancements for our mocking setup to simplify processes and improve test coverage. From d7714212f060f1749d6efb77926b175bcc94da8d Mon Sep 17 00:00:00 2001 From: Yande Date: Thu, 7 Nov 2024 15:20:34 +0000 Subject: [PATCH 9/9] change response strucutre --- docs/testing/e2e/mobile-e2e-mocking.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/docs/testing/e2e/mobile-e2e-mocking.md b/docs/testing/e2e/mobile-e2e-mocking.md index 1f6f906..338e75d 100644 --- a/docs/testing/e2e/mobile-e2e-mocking.md +++ b/docs/testing/e2e/mobile-e2e-mocking.md @@ -31,7 +31,6 @@ root/ │ │ │ ├── gas-api-responses.json ``` - This structure promotes clear organisation and makes managing tests simpler. ## Mock Server Implementation @@ -90,12 +89,10 @@ export const mockEvents = { }; ``` -Mock responses are saved in separate JSON files (`mockResponses.json`) for reusability and easier management. - ### Response Structure -Mock responses are stored in individual JSON files for each API or service, making them easier to maintain. Each file contains keys for the API and subkeys for various scenarios. +Mock responses are stored in individual JSON files for each API or service within the `mock-responses` folder, making them easier to maintain and manage. Each API service has its own JSON response file, such as `gasApiResponse.json` for gas-related responses and `ethpriceResponse.json` for Ethereum price responses. This organisation enables clear separation of mock data and simplifies updates or additions. -**Example:** `gas-api-responses.json` +**Example:** `gasApiResponse.json` ```json {