Testing in fast, reliable conditions is both the easiest and least representative way to test your mobile and web apps .
In real life, users shift between Wi-Fi and cell, experience latency, and sometimes lose connectivity altogether. If you ignore these conditions, you risk letting defects slip through undetected and offering a frustrating experience for significant numbers of users.
Ensuring your CI strategy covers representative network conditions testing is the easiest way to avoid this. Here’s why network simulation is one of the most important tools in your testing toolbox, and how to use it to test apps under slow and unstable conditions.
Summary: How Do You Test Apps Under Slow and Unstable Network Conditions?
You can test how your app behaves under unstable network conditions by simulating these conditions in repeatable, CI tests. The best approach is to prioritize testing flows that require a high degree of connectivity. Some automated testing tools , such as Momentic , offer features that make the process smoother and easier for busy engineering teams.
The table below provides an at-a-glance reference for key network conditions to test under, and what a good outcome for users might look like in each instance.
| Network condition | What to test | What ‘good’ looks like |
|---|---|---|
| Slow connection | Loading states, responsiveness, timeouts | Users get clear feedback and critical content eventually loads |
| High latency | Delayed requests, retries, duplicate submissions | Actions complete correctly without duplicate results |
| Intermittent connection | Connection drops and recovery | Failed requests are handled clearly, and user data is preserved |
| Offline | Core offline functionality and failed requests | The app fails gracefully and tells users what happened |
| Reconnection | Sync, retries, and final application state | Data synchronizes correctly, and the app returns to a consistent state |
Why Is Network Conditions Testing So Important?
Users aren’t always simply ‘online’ or ‘offline’. They might have connections that are technically available but slow enough to cause requests to time out. Latency can fluctuate, and users can move between different networks while on the move.
So, what happens if they hit the ‘Submit’ button as they lose connectivity in a tunnel?
Your mobile and web app testing workflows need to verify that features don’t just work, but that they work when the network isn’t behaving as users would like it to. This is not simply an infrastructure problem; engineering teams adjust features to provide a better experience under poor network conditions. These adjustments need to be tested in the same way as the rest of your app.
How Do You Test Apps Under Slow and Unstable Network Conditions?
Network simulation is your best friend here. By reproducing different connectivity conditions in a controlled test environment, you can test for issues that would otherwise be difficult to surface. Common network conditions to test include:
- Reduced bandwidth
- Increased latency
- Intermittent connectivity
- Offline operation
- Connection drops
- Request delays and timeouts
- Network recovery and reconnection
Testing these conditions in CI applies the same condition to the test each time. This gives you control and repeatability that would be very difficult to achieve by testing them manually.
What About Request Mocking?
Request mocking is a useful complementary tool to network simulation because it solves a different, but related, problem.
Whereas network simulation changes the network conditions you’re testing under, request mocking changes what a particular endpoint returns. For example, you might use network conditions to test a flow under high latency, and request mocking to verify how the UI handles specific server-side errors.
Momentic supports request mocking for intercepting network requests, returning controlled data, overriding feature flags, and forcing error states.
How To Test Apps Under Slow and Unstable Network Conditions: A 5 Step Process
You will not be able to test your mobile or web apps under every network condition that your users experience. Instead, test a prioritized list of user journeys against a defined set of network profiles.
1. Prioritize Which User Journeys to Test
High-connectivity workflows go at the top (e.g., logging in, submitting forms, searching data). Ones that aren’t so connectivity-dependent go at the bottom. Then introduce progressively more difficult conditions.
2. Test Reduced Bandwidth
Bandwidth throttling helps you assess whether your app is usable when data transfer is constrained. Test user journeys under a slower connection to verify that:
- Loading states appear correctly
- Critical content eventually renders
- Buttons do not trigger duplicate actions
- Requests do not fail unnecessarily
- The UI remains responsive
Look beyond immediate functional requirements. “The page loaded” still might be a poor UX if users aren’t reassured that it’s still working as it does so, for example.
3. Test High Latency
When requests take longer to complete, applications can expose race conditions, premature timeouts, duplicate submissions, and incorrect assumptions about response order. Ensure one action (e.g., hitting ‘Submit’) results in one response, even when taking longer than usual.
4. Test Intermittent Connectivity
Simulate conditions where network connections dip in and out, and ensure this doesn’t negatively affect application behavior. For example, failed requests should be surfaced clearly,
automatic retries occur only when appropriate, and user-entered data should be preserved.
5 Test Fully Offline Operation
What should the user be able to do without connectivity? Verify that any actions the user can take while offline function as intended.
For browser-based testing, Momentic’s ‘offline’ command disables network connectivity until `online` is called. This makes offline testing easier to integrate into repeatable automated workflows.
Network Simulation and Flakiness: What You Need to Know
You need to build your tests in a way that distinguishes between network instability and instability in the test itself.
What to do: make expected behavior explicit.
What not to do: liberally add retries whenever a network test fails (this conceals genuine defects).
If an app retries a failed action, make sure it succeeds without creating duplicates. If an action fails because the user is offline, make sure the app clearly tells the user what happened and handles their data safely.
Some automated testing tools, such as Momentic, offer failure recovery mechanisms to help distinguish between noisy failures and genuine product regressions. This helps tests recover from UI issues while preserving original intent.
Good Assertions For Network Conditions Testing
Keep these explicit and focused on user-centric outcomes. For example, for slow-loading pages, verify that the expected interface eventually appears. For reconnection, verify that data synchronizes correctly and that the final state is consistent.
For added reliability, you should also consider negative assertions, such as:
- No duplicate records are created
- No data is silently discarded
- No infinite loading state remains
- No misleading success message appears after a failed operation
- No stale data is presented as current without appropriate indication
Why Should Network Conditions Testing Live In CI?
You cannot run consistent network conditions testing manually . CI gives it the repeatability needed for results to be genuinely useful. Start with a small matrix covering the highest-risk conditions, then expand:
| Scenario | What to validate |
|---|---|
| Normal connection | Baseline workflow |
| Slow connection | Loading, responsiveness, timeouts |
| High latency | Retries, duplicate actions, state handling |
| Intermittent connection | Recovery and data preservation |
| Offline | Graceful failure and offline functionality |
| Reconnected | Synchronization and state recovery |
Run the most critical scenarios on pull requests, with broader network coverage on scheduled or pre-release runs if execution time is a concern.
For efficiency and reliability, keep tests short and focused. A short test that verifies one important behavior is easier to address than a large one with lots of unrelated assertions.
Network Conditions Testing: How Momentic Helps
Momentic makes network conditions testing more efficient for both native mobile and web apps. Writing tests in natural language allows you to increase coverage quickly, and offline/restore commands for web apps make it straightforward to test failure, recovery, and synchronization. Teams can also combine network scenarios with request mocking to control specific backend responses and test error states.
Deploy Multiple Times a Day While Minimizing Defects
“We’ve been adamant about leaning on the best tools available to support our team as we scale. That’s why we use Momentic for testing.”
AI text identification platform GPTZero found that their product was evolving faster than Cypress could keep pace with it. Instead of throwing headcount and engineering hours at the problem, they implemented Momentic to automate end-to-end testing.
This resulted in an 89% decrease in defect escape rate, alongside 80% faster release cycles and an acceleration of 75% in test creation times.
Get in touch to see what Momentic could do for your team.