Check failure paths safely
A blocker that works on the developer's desk can still fail on an ordinary Tuesday night. Testing what happens when things go wrong, rather than only when they go right, is what turns a prototype into something you understand. The safest tests never involve real gambling content at all.
Test with domains you control
Some domain names are reserved for documentation and testing. The .test, .example and .invalid top-level names, along with example.com, example.net and example.org, are set aside for this purpose. Put names such as blocked-test.example on your blocklist, point them at a small local web server or a static page you host yourself, and check whether the blocker intervenes.
This tests the mechanism exactly as well as a live site would, and it avoids exposing anyone, including the developer, to gambling pages and promotions. If a test ever needs a real public domain, use a harmless one you own.
Decide fail-open or fail-closed
Every component will break at some point. Fail-closed means blocking continues or widens when something breaks; fail-open means traffic flows normally. Neither is always right: failing closed can cut off the whole internet, and a user who loses internet access will remove the app. Make the choice per component and record it.
| Component fails | If it fails open | If it fails closed |
|---|---|---|
| Blocklist file cannot load | Nothing is blocked until the next successful load | The last known good list stays in force |
| Filter service is stopped | Browsing continues unfiltered | Connections are held until the service restarts |
| Upstream DNS unreachable | The system falls back to another resolver | Name lookups fail and pages do not load |
| Override timer state is lost | The override stays active | Blocking is restored immediately |
A sensible default for a personal blocker is to keep the last good list, restore blocking when timer state is unclear, and tell the user plainly when the filter is not running.
Run the failure-path checklist
After each test, record whether a listed test domain was blocked and whether normal sites still worked.
- Restart the device and test before opening the app
- Force-stop the app, then wait and test again
- Leave the device idle long enough for battery optimisation to act
- Install an operating system update, then an app update
- Switch from Wi-Fi to mobile data and back; toggle flight mode
- Turn on another VPN app
- Enable encrypted DNS in the browser settings
- Try a private window, a second browser and an in-app browser
- Test upper-case, subdomain and internationalised variants of a test domain
- Replace the blocklist file with an empty or damaged one
- Change the device clock forward during an override wait
- Start an uninstall and note what the platform allows
Make timers survive tampering
Delays and commitment windows are only as strong as the clock behind them. Wall-clock time can be changed in settings, so measure elapsed time with the platform's monotonic or boot-relative clock where possible, and store the start point persistently. After a restart, when elapsed time cannot be proven, treat the wait as not yet complete. A clock change should only ever lengthen a wait, never shorten it.
Turn results into honest notes
Keep a simple test log with the date of each run, the device and system version, each check and its outcome. Anything that failed and cannot be fixed belongs in the app's limits screen in plain words, such as "Blocking pauses if another VPN is turned on." Repeat the checklist after every system update, because background rules and network features change between versions.