r/javascript • u/allium-dev • 4d ago
Browser Test: A browser-based automated javascript testing framework in one .html file
https://github.com/swans-one/browser-testHi r/javascript! I want to share a small javascript testing project I wrote.
When I write small javascript projects that use browser APIs (most recently working with IndexedDB) I often choose not to write tests because it's a pain to either mock those interfaces server-side, and it's also a pain to setup a browser automation tool.
To solve this, I wrote up a super concise testing framework (~140 lines of JS) inside a html file that can just be dropped into a project and act as a simple test framework.
This obviously doesn't work in all situations. A big drawback is that there's no reasonable way to connect it to a CI pipeline. However for small projects, and during development, I've found it really fun and fast to use.
I'm very interested to hear what you think, or if you have other ways you've approached this situation in the past.
3
u/EveYogaTech 4d ago
I just use playwright with JS in evaluate.
This seems to be one of those things that you might forget to disable in prod and then be exposed to XSS issues.
1
u/allium-dev 4d ago
Yeah, so far I've only run it with a separate server on localhost, I agree you wouldn't want to run it in prod.
Can you say more about XSS issues? Would the issue come from the way the framework is constructed or from how some specific type of test written in it is constructed? I haven't written tests in any way that responds to user input, are you imagining something along that line?
1
u/EveYogaTech 4d ago
Well, a similar tool I used for pentesting had a listener, so you can send JS code directly to the frontend.
This is obviously risky, but for development (and pentesting) it could help since you could basically control any browser window that has it active.
Tool name: BeEF
1
u/Warm_cloud8020 3d ago edited 3d ago
Interesting approach.
We published an MCP setup for browser testing, with management tool: https://github.com/rakutentech/sorify
Let me see if your's can work with it, to be able to solve CI pipeline that ways.
Some of our projects also struggle with mocks, and we end up running a post hook to remove the test data.
Author of Sorify OSS here
2
u/Specialist_Sun_1690 1d ago
This is pretty close to something I've been experimenting with as well. I also found that having the tests run directly in the browser during development makes small frontend projects much nicer to test.
In my case I went a bit further with the idea: unit/integration tests with Testing Library, request mocking, and a CLI for running the same tests headlessly in CI.
I actually have a small vanilla JS example with no bundler/build step if you're interested: https://github.com/BRIKEV/twd-vanillajs
It's all based on this tool https://twd.dev/
•
u/allium-dev 6h ago
Interesting, thanks for sharing!
To compare the approaches: we shared the goal of tests running in the browser, but my while my library aims for being very self contained with <150 lines of JS, your library aims for more features including CI.
So for you was the main attraction of this approach that you have access to the browser dev tools as you're running tests? Or was the goal more that you enable user interaction and visual feedback during the tests?
Maybe this question is a little wrongheaded / out there, but is there any overlap between your tool and a component management tool like storybook/patternlab?
3
u/evoactivity 4d ago
Did you come across testem? Been doing testing in real browsers for over a decade. You can start super simple and scale up to more complex setups.
https://github.com/testem/testem