cwspy.com · July 30, 2026 · 7 min read
How to Test a Chrome Extension Before You Submit It
Testing a Chrome extension before you submit it catches the problems that are cheapest to fix before review and most expensive to fix after: a broken permission, a service worker that silently stops responding, a popup that only works in one theme. This is a practical checklist for testing a chrome extension end to end, written for the gap between "it works on my machine" and "it works for the reviewer, and for every user after that."
Chrome extension testing does not need a heavy framework to be effective — most of what follows is a manual pass you can run consistently before every submission.
Load and smoke-test before anything else
- Load the unpacked extension from chrome://extensions (developer mode on) and confirm it installs cleanly, with no console errors on load.
- Click through every surface the extension exposes — popup, options page, any injected UI — once each, on a real page, not a blank tab.
- Check the service worker (or background page) logs specifically; errors there are easy to miss because they do not surface in the popup's own console.
The checklist that catches what a quick smoke test misses
| Area | What to test | Why it matters |
|---|---|---|
| Permissions | Does the extension still work if you deny an optional permission, and does it fail gracefully rather than crash? | Reviewers and users both notice over-broad or unused permission requests |
| Fresh install vs. update | Test both a clean install and updating from a previous version, especially if you changed stored data formats | Update-path bugs only show up on real users, not fresh test installs |
| Light and dark theme | Check every UI surface in both | A popup readable only in one theme loses half your users without a single bug report explaining why |
| Multiple tabs and windows | Confirm behavior when the extension runs in more than one tab or window simultaneously | State bugs that only appear under concurrency are among the hardest to debug from a support ticket |
| Offline / slow network | Test with network throttled or disabled if the extension talks to any API | A silent hang with no error message reads as "broken" to a user, not "waiting" |
| Uninstall and reinstall | Confirm no orphaned state causes odd behavior on reinstall | Common source of confusing bug reports from returning users |
If you only test the happy path — extension loads, one click works, done — you are testing what already worked in development. The checklist above is for the parts that only break in front of a real user.
Testing a Manifest V3 migration specifically
If this test pass follows a Manifest V3 migration, add a few migration-specific checks: does state survive the service worker being unloaded and restarted, does anything that used to rely on blocking webRequest still function under declarativeNetRequest, and did any host_permissions get dropped that a feature still depends on. Our Manifest V3 guide and, for blocker-type extensions specifically, Manifest V3 and ad blockers cover what typically breaks.
Before you hit submit
- Re-read your manifest permissions list and remove anything the current build no longer needs.
- Test on a second, clean machine or profile if you can — your dev profile has state a fresh install never will.
- Confirm the store listing screenshots still match the current UI, not an older version.
- Have one other person click through it — a second pair of eyes catches what familiarity hides from you.
None of this replaces automated testing if your extension is complex enough to warrant it, but for most Chrome extensions this manual pass, run consistently before every submission, catches the bugs that actually generate one-star reviews.