Setting up Appium for React Native e2e - Automation Testing
Published on
·
February 23, 2026
Last updated on
·
February 16, 2026
Time to read
·
12
Pablo Marcano
End to End (e2e) testing is a technique that helps ensure the quality of mobile applications in an environment as close to real life as possible, testing the continuous integration of all the pieces that integrate a software automatically. On a mobile app, this could be particularly useful given the diversity of real devices and platforms our software is running on top of.
Due to the cross-platform nature of React Native, e2e testing proves to be particularly messy to work on. As a result, we have to write all of our tests bearing this in mind, changing the way we access to certain properties or query elements no matter the tool we use for connecting to it. Still, automation testing tools like Appium and WebdriverIO allow us to work over a common and somewhat standard interface.
The following instructions assume we already have React applications built with expo, and use Jest for our unit-testing solution.
Disclaimer: The following instructions are based on a Windows machine running an android emulator. output/commands may vary slightly on different architectures.
Setting Up Appium
Install required dependencies
$ npm i -D webdriverio babel-plugin-jsx-remove-data-test-id concurently
WebdriverIO will work as our “client” for the appium server in the case of JS. There is more to come regarding how to use other clients such as python.
babel-plugin-jsx-remove-data-test-id will help us remove unwanted accessibilityLabels from our mobile app, since that’s the preferred way of targeting elements for both IOS and Android platforms
concurrently will help us automate the running of appium server and jest to do our e2e tests
Install Appium Doctor
$ npm install appium-doctor -g
This will help us identify if we have all of the needed dependencies to correctly run appium in an emulator.
Run Appium Doctor
Depending on the host OS we want to test in, we could run:
$ appium-doctor --android
or
$ appium-doctor --ios
For this particular case I’ll be running the android version. This will prompt some output on the console. If we have all the required dependencies installed we should see a message similar to the following
If not all necessary dependencies are met at this point, instead of checkmarks before any given item you’ll see a red X symbol. Check the end of the input for more information on how to fix the particular Issues you’re prompted.
We’re not going to fix the optional requirements that appium-doctor prompts for the time being, feel free to go over those once you have the testing solution working.
Run Appium
By this point, you should be able to run your appium server without any issues, in order to do so just type
$ appium
You should see something similar to
If you do so, congrats! you have correctly set up appium.
Now, let's set up our tests.
Write tests once, run in any platform
One of the key features of React Native is its ability to write code once and run it in both iOS and Android, that is what we want our mobile tests to behave in the same way. There are some limitations for this, since the only way we can write a selector for both platforms is through the accessibilityLabel attribute in React Native.
This may become an issue if your mobile app depends on accessibility features. Make sure to use correct, semantic and descriptive accessibility labels at any place you intend to use them.
If a great accessibility is not on the scope of your current project (it should), you can use accessibilityLabel as a perfect target for querying your elements, just make sure you don’t accidentally worsen the experience of people using screen readers or any other assistive technology.
In order to do this, we’re going to configure our babel setup to remove the accessibility labels whenever we build for production:
That may be a lot of new code to digest at once, so let’s go line by line:
import wdio from 'webdriverio';
First, we import the WebdriverIO client. This is the main package that will include the functionality we need to query elements from the react app and simulate events on the emulator.
jasmine.DEFAULT_TIMEOUT_INTERVAL = 60000;
This will tell our test runner (in this case jest) to make the tests error after a certain number of ms have passed. Here we’re setting it explicitly in the test, but if you’re using jest you can modify the testTimeout property on your jest configuration. If you’re using any other test runner, I’d recommend going through their documentation, most of them have a similar property.
These are the configurations for our driver to know what to look for when using the appium interface to query and save elements.
You can get the device name going on your emulator > help > about
In order to generate an app from expo, you have to run the command:
expo build:android
And wait in the queue for it to build.
In this case, I placed the downloaded apk in the root folder for my project, and renamed it my-app-name.apk.
Since we’re using WebdriverIO, the automationName will be UiAutomator2, as that’s how appium recognizes it.
Since lines 18-33 are mostly about setup, we won’t focus on that for now. The next part focuses on line 34 and forward.
Writing the actual test
The idea of this test is just to showcase a normal flow on a test, therefore we will be dealing with a fairly simple use case: Checking that we have a valid username input:
const field = await client.$('~username'); const visible = await field.isDisplayed();
The first line allows us to query an item by accesibilityLabel. As I have previously mentioned, for more information about specific selectors go to the WebdriverIO documentation.
The second line checks whether our previously selected item is visible on the current screen, more information here.
await field.addValue('testUsername');
This line simulates user typing into the selected field. In this case, we’re inserting the ‘testUsername’ text inside the previously selected username field:
Lastly, we use Jest to check that the field is indeed visible on our Login Screen, and that the text on the given username field is the same as the one we wrote in it.
Running the test
Since we’re using Jest as our test runner on our React Native app, I’ve set up a command on my package.json to run the appium server and to run Jest in watch mode at the same time. It looks like this:
Here we’re using concurrently, a simple npm package that allows us to run several npm scripts at the same time. In this case we run the appium server and jest in watch mode, add their names and different colors to easily recognize them in the console, and pass the standard input to the jest command. This way we can narrow down our tests or do things like run coverage reports.
With this done, we simply have to run npm run test:e2e on our console, and expect something like this:
to be run, and something like this:
to be the output. If so, congratulations, you’ve correctly set up your integration tests for your react native app.
Wrapping up
While we’re far away from calling it a day on our e2e react app testing solution, the main automation testing setup it’s done. Next steps include integrating it with a CI/CD pipeline and making it work on IOS platforms.
End to End (e2e) testing is a technique that helps ensure the quality of mobile applications in an environment as close to real life as possible, testing the continuous integration of all the pieces that integrate a software automatically. On a mobile app, this could be particularly useful given the diversity of real devices and platforms our software is running on top of.
Due to the cross-platform nature of React Native, e2e testing proves to be particularly messy to work on. As a result, we have to write all of our tests bearing this in mind, changing the way we access to certain properties or query elements no matter the tool we use for connecting to it. Still, automation testing tools like Appium and WebdriverIO allow us to work over a common and somewhat standard interface.
The following instructions assume we already have React applications built with expo, and use Jest for our unit-testing solution.
Disclaimer: The following instructions are based on a Windows machine running an android emulator. output/commands may vary slightly on different architectures.
Setting Up Appium
Install required dependencies
$ npm i -D webdriverio babel-plugin-jsx-remove-data-test-id concurently
WebdriverIO will work as our “client” for the appium server in the case of JS. There is more to come regarding how to use other clients such as python.
babel-plugin-jsx-remove-data-test-id will help us remove unwanted accessibilityLabels from our mobile app, since that’s the preferred way of targeting elements for both IOS and Android platforms
concurrently will help us automate the running of appium server and jest to do our e2e tests
Install Appium Doctor
$ npm install appium-doctor -g
This will help us identify if we have all of the needed dependencies to correctly run appium in an emulator.
Run Appium Doctor
Depending on the host OS we want to test in, we could run:
$ appium-doctor --android
or
$ appium-doctor --ios
For this particular case I’ll be running the android version. This will prompt some output on the console. If we have all the required dependencies installed we should see a message similar to the following
If not all necessary dependencies are met at this point, instead of checkmarks before any given item you’ll see a red X symbol. Check the end of the input for more information on how to fix the particular Issues you’re prompted.
We’re not going to fix the optional requirements that appium-doctor prompts for the time being, feel free to go over those once you have the testing solution working.
Run Appium
By this point, you should be able to run your appium server without any issues, in order to do so just type
$ appium
You should see something similar to
If you do so, congrats! you have correctly set up appium.
Now, let's set up our tests.
Write tests once, run in any platform
One of the key features of React Native is its ability to write code once and run it in both iOS and Android, that is what we want our mobile tests to behave in the same way. There are some limitations for this, since the only way we can write a selector for both platforms is through the accessibilityLabel attribute in React Native.
This may become an issue if your mobile app depends on accessibility features. Make sure to use correct, semantic and descriptive accessibility labels at any place you intend to use them.
If a great accessibility is not on the scope of your current project (it should), you can use accessibilityLabel as a perfect target for querying your elements, just make sure you don’t accidentally worsen the experience of people using screen readers or any other assistive technology.
In order to do this, we’re going to configure our babel setup to remove the accessibility labels whenever we build for production:
That may be a lot of new code to digest at once, so let’s go line by line:
import wdio from 'webdriverio';
First, we import the WebdriverIO client. This is the main package that will include the functionality we need to query elements from the react app and simulate events on the emulator.
jasmine.DEFAULT_TIMEOUT_INTERVAL = 60000;
This will tell our test runner (in this case jest) to make the tests error after a certain number of ms have passed. Here we’re setting it explicitly in the test, but if you’re using jest you can modify the testTimeout property on your jest configuration. If you’re using any other test runner, I’d recommend going through their documentation, most of them have a similar property.
These are the configurations for our driver to know what to look for when using the appium interface to query and save elements.
You can get the device name going on your emulator > help > about
In order to generate an app from expo, you have to run the command:
expo build:android
And wait in the queue for it to build.
In this case, I placed the downloaded apk in the root folder for my project, and renamed it my-app-name.apk.
Since we’re using WebdriverIO, the automationName will be UiAutomator2, as that’s how appium recognizes it.
Since lines 18-33 are mostly about setup, we won’t focus on that for now. The next part focuses on line 34 and forward.
Writing the actual test
The idea of this test is just to showcase a normal flow on a test, therefore we will be dealing with a fairly simple use case: Checking that we have a valid username input:
const field = await client.$('~username'); const visible = await field.isDisplayed();
The first line allows us to query an item by accesibilityLabel. As I have previously mentioned, for more information about specific selectors go to the WebdriverIO documentation.
The second line checks whether our previously selected item is visible on the current screen, more information here.
await field.addValue('testUsername');
This line simulates user typing into the selected field. In this case, we’re inserting the ‘testUsername’ text inside the previously selected username field:
Lastly, we use Jest to check that the field is indeed visible on our Login Screen, and that the text on the given username field is the same as the one we wrote in it.
Running the test
Since we’re using Jest as our test runner on our React Native app, I’ve set up a command on my package.json to run the appium server and to run Jest in watch mode at the same time. It looks like this:
Here we’re using concurrently, a simple npm package that allows us to run several npm scripts at the same time. In this case we run the appium server and jest in watch mode, add their names and different colors to easily recognize them in the console, and pass the standard input to the jest command. This way we can narrow down our tests or do things like run coverage reports.
With this done, we simply have to run npm run test:e2e on our console, and expect something like this:
to be run, and something like this:
to be the output. If so, congratulations, you’ve correctly set up your integration tests for your react native app.
Wrapping up
While we’re far away from calling it a day on our e2e react app testing solution, the main automation testing setup it’s done. Next steps include integrating it with a CI/CD pipeline and making it work on IOS platforms.
Applying changes across microservices is difficult because business logic is distributed across multiple services, each with its own data, contracts, and responsibilities.
In our experiment at Kaizen Softworks, we tested whether an AI system could safely apply coordinated changes across a microservices architecture using only minimal input.
Short answer: Yes, but only when the AI has enough architectural context.
Why are coordinated changes in microservices so hard?
In distributed systems, a single business change rarely affects just one service.
It often requires:
Updating multiple microservices
Modifying message contracts
Keeping DTOs (Data Transfer Objects) consistent
Respecting domain boundaries defined by Domain-Driven Design (DDD)
Key entities in this system:
Microservice: An independently deployable service responsible for a specific domain
Aggregate (DDD): A cluster of domain objects treated as a single unit
DTO (Data Transfer Object): A structured format used to transfer data between services
Message/Event: A communication mechanism between services
The complexity is not in the code, it’s in the relationships between components.
The experiment: Can AI reason across services with minimal input?
We designed a controlled experiment to test whether an AI model could apply system-wide changes with limited information.
Input given to the AI:
Message definitions (events between services)
DTOs (data contracts)
Tasks the AI had to perform:
Identify affected aggregates
Determine service ownership
Apply coordinated changes across services
Maintain consistency in messages and DTOs
In other words, the AI had to behave like a software architect, not just a code generator.
What was the biggest obstacle?
The biggest challenge was not technical, it was contextual.
Problem: unclear service naming
Instead of descriptive names like:
order-service
billing-service
Our services were named:
john
sally
roger
This removed any semantic clues about responsibility.
Result: The AI could not infer which service owned which domain logic.
The missing piece: aggregate ownership mapping
To solve this, we introduced a simple but powerful structure:
Aggregate → Service mapping
Order → john
Shipment → sally
Invoice → roger
This created a clear relationship between domain concepts and system components.
Once ownership was explicit, the architecture became understandable.
How we used AI to generate architectural context
Instead of building this mapping manually, we used AI to analyze the codebase and extract:
Where each aggregate was defined
Which microservice implemented it
The relationship between domain and infrastructure
The result was a machine-readable architecture map.
In practice, we used AI to generate the context that AI itself needed.
Results: Can AI safely apply distributed changes?
With the architecture map in place, the AI was able to:
Trace message flows across services
Identify affected aggregates
Locate the correct microservices
Apply coordinated updates
Maintain consistency between DTOs and messages
While not perfect, the system worked reliably as a proof of concept.
What is the real limitation of AI in microservices?
The main limitation of AI is not code generation, it’s architectural understanding.
Without knowing:
Which components exist
How they relate
Who owns what
AI cannot safely modify a distributed system.
AI performance depends more on context quality than model capability.
When can AI safely modify microservices?
AI works well when:
Aggregate ownership is clearly defined
Message contracts are explicit
Architecture is structured and consistent
AI struggles when:
Naming is ambiguous
Relationships are implicit
Context is incomplete
Simple rule: If the architecture is clear, AI can reason. If not, it guesses.
Final thoughts
This experiment revealed something important:
AI doesn’t fail because it can’t write code. It fails because it can’t see the system.
As teams move toward AI-assisted development, the focus will likely shift from:
Writing better code to Designing better systems for machines to understand
At Kaizen Softworks, we see this as a foundational shift.
Because when AI can understand architecture, it doesn’t just generate code, it helps evolve systems.
There's a myth that in flat organizations, everyone decides on everything.
That's not how it works. At least not at Kaizen.
When people hear "no managers," they often picture one of two extremes: either total chaos where nobody is accountable, or endless meetings where 80 people vote on which coffee to buy. The reality is neither.
Not everyone decides on everything. Not everyone votes. What we do have is a clear set of decision-making methods that we choose based on context.
It depends on who's affected and how deep the impact goes
Before choosing how to decide, we ask ourselves a few questions:
Who is affected? A decision that only impacts one team doesn't need the whole company involved. A decision that affects everyone's daily work does.
How deep is the impact? Changing the office furniture is wide but shallow. Changing the salary model is deep and lasting.
Is it reversible? If we can easily undo it, we can move fast and just inform. If it's hard to reverse, we slow down and include more people.
How urgent is it? And here we're careful to distinguish real urgency from anxiety, the pressure to decide quickly because someone already has "the answer" in mind.
These dimensions help us pick the right method. Not every decision deserves the same process.
Our decision-making toolkit
Over the years, we've landed on a few methods that we use depending on the situation:
1. Role-based decisions
Some decisions belong to a specific role. If someone owns a responsibility, say, office logistics or hiring for a team, they decide within that domain. No committee needed. The key is that roles are transparent: everyone knows who owns what, and the scope of each role's authority is clear.
2. Advice Process
When a decision doesn't clearly belong to one role, or when it crosses boundaries, we use the advice process. Here's how it works:
Someone takes the initiative. They identify the problem and own the process.
They gather input from people who are affected and people with expertise.
They seek advice, real conversations, not rubber-stamping.
They make the decision and communicate it, including what advice they incorporated and what they didn't (and why).
The decision-maker is not a committee. It's one person (or a small group) who takes responsibility. But they don't decide in isolation, they bring in the perspectives that matter.
We sometimes call this "Team Advice" when a working group forms around an issue that doesn't naturally fall into anyone's area, and "Area Advice" when a team opens up a topic that exceeds their own scope.
3. Consent (not consensus)
Consent is not "everyone agrees." Consent means "no one has a strong enough objection to block this." We do use a poll, but not to count votes — we use a 1-to-5 scale to measure the level of agreement and surface objections, not to let the majority rule.
We use it in two flavors:
High-participation consent: For decisions with deep, company-wide impact. This is our most expensive and slowest method, which is exactly why we reserve it for high-impact decisions that affect many people. The Board sets the boundaries, for example, when we moved offices, they defined the monthly budget. Then a working group produced proposals, collected feedback, evolved them, and the whole company expressed their position for the final decision. Silence is not approval; we explicitly ask people to weigh in, even if it's just "I have no objection."
Lightweight consent: For decisions that are broad but not deep. Participation is optional, anyone who's interested can jump in. We share the proposal, open a window for objections, and if nobody opposes, we move forward. This gives us speed without sacrificing transparency. If nobody engages, that's a signal too, maybe the proposal doesn't add enough value, or we're using the wrong channel.
4. Inform, don't fake-consult
Not everything needs participation. When a decision has already been made through a legitimate process, the right move is to inform, not to fake-consult. One of the fastest ways to kill self-management is to ask for feedback and then ignore it. If you're not going to change course based on input, don't ask for it, just be transparent about the decision and the reasons behind it.
What we explicitly avoid
Decision by Voting. In a company context, majority rule creates losers. And losers become detractors, often generating more resistance than an autocratic decision would have. Instead of voting, we prefer to evolve a proposal through feedback until it's "good enough for now," and then introduce a review point to adjust later. If voting happens at all, it's the cherry on top, not the main course.
The "surprise" approach. Working behind closed doors and then unveiling a finished decision is a recipe for frustration. Adults don't need surprises. Adults need to feel like they're part of the process. The complaints that follow a surprise aren't about the decision itself, they're about not being included.
Why we work this way
We didn't adopt these methods because they're trendy. We adopted them because they solve real problems:
Better decisions. When you include affected people, you get information you wouldn't have had otherwise. Ideas emerge that no single person would have come up with alone.
Less resistance. A person who feels heard is far less likely to resist a decision, even one they wouldn't have made themselves.
Faster execution. It sounds counterintuitive, but participative decisions often execute faster because people already understand and support them. The time you "save" by deciding alone, you spend later managing pushback.
Distributed authority. When people can make decisions within their domain without escalating everything to a founder, the organization scales. The bottleneck disappears.
Resilience. If a shared decision fails, the group adjusts together. If a top-down decision fails, the blame falls on one person and the chances of proactive correction drop.
The real principle behind all of this
Transparency is the foundation. Every method we use, from role-based decisions to high-participation consent, works because information flows openly. People know what's being decided, who's deciding it, and how they can participate.
Horizontal doesn't mean structureless. It means fewer hierarchical levels, clearer roles, and intentional decision-making processes that match the weight of each decision.
Not everyone decides on everything. But everyone knows how things get decided.
.png)
