Test an app with no internet
Pulling the network cable tests one thing: a machine with no network. Most offline bugs are not that. They happen when the adapter is up, the WiFi icon looks fine, and the thing the app needs is simply not reachable.
Three different kinds of "offline"
| What you switch on | What the app sees | The bug it finds |
|---|---|---|
| LAN mode | The local network works. Anything beyond it does not. | Hotel WiFi before you log in, a dead uplink, a company network with no route out. |
| Block an address | One server is unreachable. Everything else works. | One dependency down while the app itself is fine - the case a health check usually misses. |
| Block port 53 | Names stop resolving, connections by address still work. | Broken DNS, which looks like "the internet is down" to a user and like something else entirely in the logs. |
From the command line
Internet gone for one application, local network untouched, for two minutes:
BeanNetworkTester.exe --lan-mode --target myapp.exe --duration 120
One service unreachable, everything else normal:
BeanNetworkTester.exe --block-ip 203.0.113.10
Names stop resolving:
BeanNetworkTester.exe --block-port 53 --target myapp.exe
There is also a ready timeline that breaks DNS and puts it back on its own -
failing-dns.json in the scenarios folder next to the program. See
timed scenarios.
What to actually look for
- The message. Does the app say what happened, or show a spinner for ever?
- The retry. Does it back off, or hammer the same address in a loop?
- The queue. Is work the user did while offline kept and sent later, or lost?
- The recovery. STOP puts the network back. Does the app notice on its own, or does it need a restart?
That last one is where most of the value is. Going offline is easy to handle badly and easy to test. Coming back is where the state gets wrong.
What this is not
The adapter stays up and the machine keeps its address, so an application that only asks Windows "is there a network" still gets yes. That is deliberate, and it is the more interesting test: real users are rarely disconnected, they are connected to something that cannot reach what they need. If you specifically want the "no adapter" case, disable the adapter - no tool needed.