Skip to content

Conversation

@descorp
Copy link
Contributor

@descorp descorp commented Jan 12, 2026

Changes

  • add workflow that allows testing integration of current version on a blank app
    • builds fixture
    • apply minimal code
    • runs Appium tests

@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @descorp, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the project's testing capabilities by introducing an automated integration testing suite. It sets up a process to build and test the adyen-react-native SDK within a newly generated, minimal React Native or Expo application. This ensures that the SDK's core functionality and integration remain stable across different environments and React Native versions, preventing regressions and providing a reliable baseline for future development.

Highlights

  • New Integration Testing Workflow: Introduces a comprehensive workflow to test the adyen-react-native SDK's integration with a blank React Native or Expo application.
  • Cross-Platform Appium Tests: Adds scripts/check-app.js which uses WebdriverIO and Appium to perform UI tests on both Android and iOS, verifying core UI elements like the 'Open DropIn' button.
  • Automated Fixture Setup: scripts/fixture_setup.sh automates the creation of new React Native/Expo projects, dependency installation (including adyen-react-native.tgz), and injection of a test App.tsx.
  • Platform-Specific Build Scripts: Includes scripts/fixture_android.sh and scripts/fixture_ios.sh for building the fixture app on their respective platforms, handling platform-specific configurations like MainActivity.kt and CocoaPods.
  • Secure Secret Injection: scripts/inject_secrets.sh ensures that sensitive API keys (ADYEN_CLIENT_KEY and ADYEN_PUBLIC_KEY) are securely injected into the test application from environment variables.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Ignored Files
  • Ignored by pattern: .github/workflows/** (1)
    • .github/workflows/blank_test.yml
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

@descorp descorp changed the title Add blank app fixture runner and appium tests CI: Add blank app fixture runner and appium tests Jan 12, 2026
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a valuable set of scripts for creating a test fixture app and running Appium tests, which is a great step towards automated integration testing. My review has identified a few critical and high-severity bugs in the shell scripts related to argument parsing and environment variable handling that would prevent them from executing correctly. I have also included several suggestions to improve the robustness of the tests and the efficiency of the scripts. Addressing these points will ensure the new testing workflow is reliable and maintainable.

@descorp descorp force-pushed the ci-blank-tests branch 2 times, most recently from b7e3f3a to 6baa0f3 Compare January 13, 2026 13:28
@sonarqubecloud
Copy link

@Adyen Adyen deleted a comment from gemini-code-assist bot Jan 14, 2026
run: |
appium --port 4723 --log-level error &
for i in {1..90}; do
if curl -sf http://127.0.0.1:4723/status >/dev/null; then
Copy link

@atmamont atmamont Jan 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this waiting for a server to start up and be ready?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct. On Ubuntu it happens pretty fast, but on Mac it take some significant time.

Copy link

@atmamont atmamont left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Amazing investment into reliability, Vlad.
I have some concerns regarding injecting secrets in the script runs using sed as it might be a sec vulnerability as they will be visible in logs.
I am not a fan of bash scripts as they are hard to maintain for anyone but author, let me take some time to think of what could be improved in terms of readability.

adb reverse tcp:8081 tcp:8081 || true

echo "== Launch App"
adb shell am start -n "$APP_PACKAGE/$APP_ACTIVITY" >/dev/null 2>&1 || true

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

|| true means it will pass it the command fails, why wouldn't we fail early here?

export IOS_UDID="$UDID"
export IOS_DEVICE_NAME="$device_name"
export IOS_PLATFORM_VERSION="$os_version"
node ./check-app.js No newline at end of file

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is quite a complex setup and is not scalable for other platforms(at least flutter). Let's think of alternative solutions?
Using meta repository pipelines that run nightly or upon a new release could be more scalable, as it uses appium repo as a submodule and you can get rid of all wrapper and setup code that would be a hell to maintain.

fi

echo "== Start Metro"
yarn start --port 8081 >/dev/null 2>&1 &

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could leave bundler running if script fails (I am not sure but it can easily burn github runner paid minutes). It's a general recommendation to catch such things, here is one suggestion from LLM:

cleanup() {
  pkill -f "node.*metro" || true
}
trap cleanup EXIT

@atmamont atmamont requested a review from Robert-SD January 14, 2026 08:58
@atmamont
Copy link

atmamont commented Jan 14, 2026

@Robert-SD we need your input here

While this is definitely a nice improvement to react native, I feel it would be hard to scale to all platforms.

Key issues:

  1. Duplicates existing infrastructure: Appium test suite in adyen-checkout-e2e-testing that covers iOS, Android, and Flutter with:

    • WebDriverIO + Page Object Model architecture (Robert is working on refactoring the engine to use Kotlin instead)
    • Centralized element mapping system
    • 7+ comprehensive test specs (not just smoke tests) and more to come when we scale this up in 2026
    • Existing CI/CD workflows that only need to be triggered with a provided app binary (it's MyStore now, could be any, as warmup phase is abstracted and you can write your own set of steps to reach the SDK flow)
  2. Limited scope: This PR only validates "can the app launch and show a button" vs. the existing infrastructure which tests full payment flows, error handling, and validation logic.

  3. Inefficient build strategy: Building apps from scratch on every test run vs. using pre-built artifacts (2-5 min execution). We don't have all the dots connected yet, but this could be an impact point where we actually plan and connect them.

Rather than maintaining separate Appium infrastructure per platform, I suggest we extend the existing adyen-checkout-e2e-testing to include React Native:

This aligns with the meta repository vision where every effort scales to all mobile platforms automatically.


Note: This is not a blocker for merging - just an invitation to think bigger picture about "SDK development" vs "platform-specific development".

@Robert-SD
Copy link
Contributor

@descorp @atmamont I really like the addition and will put the PR into perspective. Here are my thoughts:

  1. Duplicated Infrastructure
  • Clean Build Test: Adding a test for creating a clean empty app project and including the SDK is valuable for verifying that the PR does not break the compilation of the SDK. This is similar to the steps in the Flutter SDK: Android workflow and iOS workflow.
  • Question on Appium: I'm not sure if Appium is truly necessary for this, or if simply building and launching the app without interacting with buttons would suffice.
    If Appium is added, we should follow our global Kotlin based approach. We can work together to reuse our centralized element mapping, for which the groundwork has already been prepared with React Native in mind.
  1. Limited Scope & E2E Testing
  • The full payment flow will be tested through the End-to-End (e2e) project, which uses shared tests across all platforms. This means there is no need to create custom React Native tests besides the steps required to reach the native SDK.
  • Netlify Layer: This setup requires the Netlify layer, similar to the MyStore demo apps.
    I've added a Netlify network layer to the Flutter example app instead of maintaining two separate apps. So we can switch just the credentials and the endpoints. We could consider doing the same for the React Native example app.
  1. Build Strategy & Dedicated Tests
  • The e2e tests run as nightlies and are not quick. Using them during the day while implementing features might be too time-consuming. A quick clean build check is nice.
  • As mentioned in point 1, I like having a dedicated "building/compilation" test inside the SDK project. Also for renovate PRs. This is where we could test the latest Gradle and Android versions, as well as the latest iOS version.

@descorp
Copy link
Contributor Author

descorp commented Jan 14, 2026

/gemini review

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a new CI workflow for running integration tests on a blank app using Appium. The changes include scripts for setting up the test fixture, running tests on both Android and iOS, and the Appium test script itself.

My review focuses on improving the robustness and maintainability of these new scripts. I've identified a couple of high-severity issues in the shell scripts related to waiting for the Metro server, which could lead to flaky CI runs. I've also found opportunities for refactoring in the Appium test script to reduce code duplication and a minor cleanup in the generated test app code. Overall, this is a great addition for improving test coverage.

Comment on lines 60 to 63
for i in {1..30}; do
nc -z 127.0.0.1 8081 && break
sleep 1
done
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

This loop waits for Metro to start, but it doesn't handle the case where Metro fails to start within the 30-second timeout. The script will continue execution, likely causing subsequent steps to fail with less clear error messages. It's better to exit with an error if the loop completes without Metro starting.

Consider changing the loop to something like this:

for i in {1..30}; do
  if nc -z 127.0.0.1 8081; then
    break
  fi
  if [ "$i" -eq 30 ]; then
    echo "Error: Metro failed to start after 30 seconds."
    exit 1
  fi
  sleep 1
done

Comment on lines 70 to 73
for i in {1..30}; do
nc -z 127.0.0.1 8081 && break
sleep 1
done
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

This loop waits for Metro to start, but it doesn't handle the case where Metro fails to start within the 30-second timeout. The script will continue execution, likely causing subsequent steps to fail with less clear error messages. It's better to exit with an error if the loop completes without Metro starting.

Consider changing the loop to something like this:

for i in {1..30}; do
  if nc -z 127.0.0.1 8081; then
    break
  fi
  if [ "$i" -eq 30 ]; then
    echo "Error: Metro failed to start after 30 seconds."
    exit 1
  fi
  sleep 1
done

Comment on lines +91 to +98
try {
const screenshotPath = './appium_failure.png';
await driver.saveScreenshot(screenshotPath);
console.error(`==> [Test] Saved screenshot to ${screenshotPath}`);
} catch (e) {
console.error('==> [Test] Failed to capture screenshot');
console.error(e);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The logic for saving a screenshot is duplicated in this file (here and in the final catch block on lines 145-152). To improve maintainability and reduce code duplication, you could extract this logic into a helper function. Also, the screenshot path './appium_failure.png' is hardcoded in two places and could be defined as a constant.

Here's a suggested refactoring:

const SCREENSHOT_PATH = './appium_failure.png';

async function saveScreenshot(driver) {
  try {
    await driver.saveScreenshot(SCREENSHOT_PATH);
    console.error(`==> [Test] Saved screenshot to ${SCREENSHOT_PATH}`);
  } catch (e) {
    console.error('==> [Test] Failed to capture screenshot');
    console.error(e);
  }
}

You can then replace the screenshot logic in both places with a single call: await saveScreenshot(driver);


name=$1
platform=$2
api_level=$3
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The api_level variable is assigned from the third script argument but it's never used. It should either be used or removed to avoid confusion.

<View>
<StatusBar barStyle={isDarkMode ? 'light-content' : 'dark-content'} />
<ScrollView contentInsetAdjustmentBehavior="automatic">
<View style={{}}>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The View component has an empty style object (style={{}}). This is unnecessary and can be removed.

Suggested change
<View style={{}}>
<View>

@Adyen Adyen deleted a comment from gemini-code-assist bot Jan 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants