The Testing Dilemma
For years, I've been on a quest to write frontend JavaScript without relying on Node.js or any server-side runtime. While this approach keeps things lightweight and self-contained, one persistent challenge has been testing. Without Node, traditional testing frameworks and orchestration tools often become inaccessible or overly complex. The result? My frontend code—especially Vue components—remained untested, leaving me uneasy when making changes. This article explores a straightforward method I recently discovered: running tests directly inside the browser, using QUnit and a few clever setup tricks.
Why Not Playwright?
I initially tried Playwright for end-to-end testing, but it felt heavy and slow. Spinning up new browser processes and managing Node-based orchestration added unnecessary overhead. Moreover, my goal was to avoid Node entirely, so relying on a tool that required it defeated the purpose. I needed a solution that could run entirely within the browser—no servers, no build steps, just pure client-side JavaScript.
A Simpler Idea: Run Tests in the Browser
Inspired by Alex Chan’s post on writing a tiny unit-testing framework, I initially focused on unit tests. But I wanted integration tests for my Vue components—testing form submissions, API calls, and UI interactions. During a conversation with Marco, he casually suggested, “You know, you can just run your Vue component tests directly in the browser.” That comment reignited my effort, and I spent a day putting it into practice. Here’s what I learned.
Choosing a Test Framework: QUnit
I opted for QUnit, a simple, browser-compatible testing framework. It worked flawlessly and required no Node dependencies. QUnit’s built-in “rerun” button was a lifesaver: because my tests involve multiple network requests, being able to rerun a single test in isolation made debugging far less confusing. You could also use Alex Chan’s DIY approach, but QUnit saved time.
Setting Up Components for Testing
To expose my Vue components to the test environment, I modified the main app to register them globally on window._components. For example:
const components = {
'Feedback': FeedbackComponent,
// ... other components
};
window._components = components;Then I wrote a mountComponent function that essentially replicated the app’s initialization—rendering a small template with Vue.createApp and mounting it to a container element. This allowed me to programmatically create any component instance for testing.
Writing the First Tests
The tests themselves followed a standard pattern: fetch dummy data (e.g., a list of feedback forms), fill in a form, submit it, and verify that the UI updates correctly. For example, one test checks that after submitting feedback, a confirmation message appears. Because the tests run in the same browser tab, I can inspect the DOM directly and even step through the code in DevTools. No extra processes, no orchestration—just a plain HTML file with QUnit and my test scripts.
Lessons Learned and Future Improvements
This approach works surprisingly well for integration testing Vue components. The biggest advantage is simplicity: everything lives in the browser, with no build tools or server runtimes. However, there are areas to refine:
- State management: Tests can interfere if they share global state. Isolation (e.g., resetting
window._componentsbetween tests) is essential. - Network mocking: Real API calls can be slow and unreliable. Adding a mock layer (e.g., intercepting
fetch) would make tests faster and more deterministic. - Component lifecycles: Vue’s reactivity and lifecycle hooks need careful handling—ensure components are properly unmounted after each test.
Despite these quirks, I’m now able to iterate on my Vue components with confidence. The browser-based testing approach eliminates the Node dependency while still providing robust end-to-end coverage. If you’ve hesitated to test frontend code because of toolchain overhead, give this method a try—you might be surprised how easy it can be.