DEV Community: Arafat

Half my test suite asserts that nothing happened

Arafat — Mon, 31 Aug 2026 14:51:45 +0000

Last month I shipped a bug where every test passed.

The extension I maintain fills web forms with test data. It has two modes: use a profile you saved yourself, or generate fresh data. A user picks "Generated test data", the extension fills the form — and quietly uses their saved profile instead.

Not a crash. Not an error in the console. The form filled. Every field had a value in it. The only thing wrong was that the values were the wrong ones, and nothing anywhere said so.

Every test in the suite was green.

Why it passed

The bug was in a fallback. The code resolved which profile to use, and when nothing matched it fell back to the first item in the list. The built-in "generated data" option isn't a saved profile, so it never matched, so it always fell through to the fallback. Once you saved a single profile, you could never choose generated data again.

Here is the part worth sitting with: the fallback did exactly what a fallback is supposed to do. It picked something reasonable instead of failing. And every test I had written asked the same kind of question — did the form get filled? Yes. Do the fields have values? Yes. Is the data valid? Yes.

Not one test asked is this the data the user actually asked for? And no test at all asked the harder version: when the user picks the built-in option, does the code correctly do nothing with the saved profiles?

That is the whole category. I had a suite full of "did it work" tests and nothing that said "did it correctly do nothing".

The tests nobody writes

Once you start looking for this, it is everywhere. Test suites are written as a description of what software should do, because that is how features are specified, planned and reviewed. "Should not" is a different question, and it does not turn up just because the "should" list got longer.

For a tool that writes into forms, the "should not" list is long and it matters more than the other one:

A CAPTCHA field must never be filled. Filling it is worse than doing nothing, because it looks like an answer.
A hidden CSRF token must never be touched.
disabled and readonly fields stay as they are.
File inputs stay empty.
Anything invisible stays untouched.
A form in a cross-origin iframe is not filled, and cannot be — reaching into another site's frame would need standing access to that site.

A filler that fails to fill a field is annoying. A filler that writes into a hidden token field and breaks the submit is worse, and the user will not know why. The failures on that list are all silent, which is exactly why they need explicit tests: nothing else will surface them.

So now, before a feature gets written, I write the refusal cases as fixtures. The question I ask about a plan is not only "is this right" but "what should this refuse to do, and what happens if it is asked to anyway". The second pass finds things the first one never surfaces. Every time.

At the time of writing, in September 2026, the suite graded 84 cases and 13 of them asserted refusal rather than success. Those 13 are the ones I would keep if I had to throw the rest away.

Mocks were part of the problem

The other half of the fix was where the tests run.

My original suite tested the field classifier and the fill engine against mock DOM objects. That is fast and it is easy to write, and it is also how the entitlement bug survived: the mocks reflected what I believed the DOM did, and the belief was the thing that was wrong.

A browser extension has a particularly bad case of this. The engine is injected into a page it has never seen, in a browser build I do not control, against a framework that patches native DOM behaviour underneath it. React, to take the most common example, keeps its own record of what is in each input. If something writes to input.value directly, React compares the DOM against that record, sees no difference, and never fires onChange. The text is on screen. The application never received it. (I wrote about that specific mechanism in more detail here.)

None of that is visible to a mock. A mock will happily tell you the value was set.

So the suite got rebuilt as a real page. It loads the same four files the service worker injects — not a copy, not a test build, the actual engine — and runs them against a page full of deliberately awkward fields:

React, Vue and Angular controlled inputs
open shadow roots, including nested ones, and custom elements
fields classifiable only by an autocomplete token
fields with no useful signal at all — no label, no placeholder, no name
field names containing dots and dashes that break naive selector matching
same-origin iframes
and the refusal cases above

73 fixtures, 84 graded cases. That run, in September 2026: 71 passed, 0 failed, 13 correctly skipped. The current score is not this one — it is whatever the suite reports when you run it yourself, inside the extension or at flinthive.com/form-filler-test.

Then I shipped the suite inside the product

This was the part I did not expect to be useful, and it turned out to be the most useful.

The self-test is not a CI artefact. It is a page inside the extension. Anyone who installs it can open it and run the real engine in their own browser, on their own build, and see the score.

Two reasons that matters.

The first is honest self-interest: browser updates break extensions. I test on my machine, on my Chrome version, in my OS. A user three versions ahead on a platform I have never touched will find failures I cannot reproduce and probably cannot even imagine. Now they can run the suite and send me a report instead of an uninstall.

The second reason is about trust, and it is the one I would repeat to anyone building a tool that touches other people's pages. My store listing makes a set of claims: it handles React, it handles shadow DOM, it leaves CAPTCHA fields alone, it makes no network requests. Anyone can write that. Screenshots prove nothing — I made the screenshot. A test suite the user runs themselves is the only version of that claim they do not have to take my word for.

"Know it works in your browser" turned out to be a better thing to offer than any feature on the list.

What it still does not catch

I want to be straight about the limits, because a scoreboard is easy to over-trust.

The bug that cost me the most money this year was not in the extension at all. A payment webhook fired on a completed transaction, and the payload did not always contain the buyer's email address — sometimes it carried only a customer id. The code was correct. The tests were correct. They were written against the payload shape in the documentation, and the documentation showed the field.

I found it on a real purchase, which is a bad way to find it.

No fixture would have caught that, because the fixture would have used the documented shape too. The only thing that catches it is logging raw payloads from live traffic and looking at what actually arrives. Fixtures test your code against your understanding. Where the understanding is wrong, they agree with you.

So: fixtures for what you control, real payloads for what you do not.

What I would tell myself a year ago

Write the refusal cases as fixtures, before the feature. Ask "what should this refuse to do" as a separate question from "is this plan right". It surfaces different answers.
Run the real code in the real runtime. Mocks encode your assumptions, and your assumptions are what is broken.
A green suite is evidence about the questions you asked, not about the software. Mine was fully green while a headline feature was silently broken.
Consider shipping the suite. If your tool runs inside somebody else's environment, letting them verify it there is worth more than another screenshot.

I build FormForge, an offline form filler for QA and development work. The self-test page described here ships with it — free tier included, no account needed. If you run it and something fails, I would genuinely like to see the report: support@flinthive.com

Why input.value = 'x' doesn't fill a React form (and what actually works)

Arafat — Thu, 20 Aug 2026 04:13:45 +0000

If you have ever tried to script a React form — a test helper, a browser extension, a bookmarklet, an onboarding demo — you have probably hit this:

document.querySelector('#email').value = 'test@example.com';

The field shows the text. It looks filled. Then you submit, and React sends an empty string. Or the "Next" button stays disabled. Or the value vanishes the moment anything else on the page re-renders.

I ran into this repeatedly while building a form-filling extension, and the fix is not obvious from React's docs. Here is what is actually happening.

React keeps its own copy of the value

React attaches a value tracker to every controlled input. It is an internal object stored on the DOM node under a property React owns, and its only job is to remember what React last saw in that field.

When a real user types, two things happen:

The browser updates input.value
The browser fires an input event

React's synthetic event system catches that event, compares the node's current value against the tracker's remembered value, sees they differ, and therefore concludes something changed and calls your onChange.

That comparison is the whole story. React does not ask "did the value change?" — it asks "does the DOM disagree with what I remember?"

Why direct assignment breaks it

HTMLInputElement.prototype.value is an accessor property with a setter. React replaces that setter on the individual node with its own version, one that updates the tracker as it writes.

So when you do input.value = 'x', you go through React's patched setter. It writes the value and updates the tracker to match. The DOM and the tracker now agree.

Then you dispatch an input event, React compares the two, finds them identical, and concludes nothing changed. onChange never fires. React's state still holds the old value, and the next render wipes your text away.

You did not fail to notify React. You notified React and React decided you were lying.

The fix: bypass the patched setter

You need to write the value without going through React's setter, so the tracker stays stale and the comparison detects a difference:

function setNativeValue(el, value) {
  const proto = el instanceof HTMLTextAreaElement
    ? HTMLTextAreaElement.prototype
    : HTMLInputElement.prototype;

  const setter = Object.getOwnPropertyDescriptor(proto, 'value').set;
  setter.call(el, value);

  el.dispatchEvent(new Event('input', { bubbles: true }));
}

Object.getOwnPropertyDescriptor(HTMLInputElement.prototype, 'value').set is the browser's original setter, untouched. Calling it with .call(el, value) writes straight to the DOM, leaving React's tracker holding the old value. Now the comparison fails, React believes you, and onChange fires.

Note the prototype check. <textarea> has its own prototype with its own value setter, and using the input one on a textarea throws.

Three more things that bite

<select> needs change, not input. Select elements notify on change. Dispatch input at a <select> and nothing happens. Checkboxes and radios need click() or a change event, not a value write at all.

Some libraries want the full keyboard sequence. A handful of masked-input and autocomplete components listen for keydown/keyup rather than input. If the native-setter approach alone does not stick, dispatching keydown, input, keyup in order usually does.

Vue 3 is easier, Angular is different. Vue's v-model listens for plain input events, so the ordinary path works. Angular's ControlValueAccessor also listens for input on most controls, but reactive forms sometimes need a blur afterwards to run validators — otherwise the field is filled and still marked untouched.

Verify the write

This is the part I would most encourage you to steal, because it changed how much time I spent debugging.

After writing a value, read it back:

setNativeValue(el, value);

// let the framework's microtask queue drain
await Promise.resolve();

if (el.value !== value) {
  // the framework rejected or transformed the input
}

If the value came back different, the page's framework rejected it — a mask reformatted it, a validator cleared it, a controlled component overwrote it on re-render. That is a completely different failure from "the selector did not match", and it needs a completely different fix.

Reporting those two cases separately turned my most common bug report from "it doesn't work" into "your app rejected this input, here is what it became" — which is actionable.

Shadow DOM: the other half of the problem

document.querySelectorAll('input') does not see inside shadow roots. A lot of modern component libraries put their real <input> inside one, so a script that works fine on a plain HTML page finds nothing at all on a component-library page.

Open shadow roots you can walk:

function* deepInputs(root = document) {
  for (const el of root.querySelectorAll('*')) {
    if (el.matches('input, textarea, select')) yield el;
    if (el.shadowRoot) yield* deepInputs(el.shadowRoot);  // nested roots too
  }
}

Shadow roots nest, so this has to recurse — a component inside a component inside a component is common, and a single-level check misses it.

Closed shadow roots you cannot reach, at all. element.shadowRoot returns null when the root was created with { mode: 'closed' }, and there is no workaround from page or extension context. This is by design. The honest thing is to detect the likely case and say so rather than silently filling nothing: a custom element with no light-DOM children and no accessible shadowRoot is probably a closed root, and telling the user that is far better than a silent no-op.

Same-origin iframes work through iframe.contentDocument. Cross-origin iframes do not, and no amount of cleverness changes that — you need an explicit host permission for that origin, which is a real cost to weigh rather than something to engineer around.

Do not fill everything you find

The last thing, and the one I got wrong first: a script that fills every field it can find is worse than one that fills nothing.

Skip these, always:

disabled and readonly fields
Anything hidden — type="hidden", display: none, zero-size, visibility: hidden
CSRF tokens — usually a hidden input with token, csrf or authenticity in the name. Overwriting one breaks the submit in a way that is genuinely hard to diagnose.
CAPTCHA fields — never touch them
<input type="file"> — you cannot set it programmatically for good security reasons, and trying throws

I ended up writing more test fixtures for the must-not-fill cases than for the fill cases, and that ratio turned out to be right.

Test it against adversarial fixtures, not happy paths

Every one of the failures above is invisible on a simple form and obvious on a real one. So the fixtures worth writing are the nasty ones: a React controlled input, an open shadow root, a nested shadow root, a same-origin iframe, a field whose only signal is an autocomplete token, a field with no signals at all, an input with dots in its name, a CAPTCHA, a hidden CSRF token.

When I wrote this, in August 2026, mine ran 56 fixtures and graded 75 cases — the extras are suite-level invariants like "one report row per discovered field" and "widget selections are deterministic". That run: 65 passed, 0 failed, 10 correctly skipped, where the 10 skips are the guard cases that should be refused. The suite has grown since, so treat those as a snapshot rather than a current score — the current one is whatever it reports when you run it yourself, in the extension or at flinthive.com/form-filler-test.

The number that matters there is the 10, not the 65. Anyone can make a suite go green by only testing what already works; refusing to fill a CAPTCHA is the harder assertion.

Try it

I packaged all of this into FormForge, a Chrome extension that fills forms with realistic test data. It ships the self-test page described above, so you can run all 56 fixtures in your own browser build rather than taking my word for any of it.

Chrome Web Store:
https://chromewebstore.google.com/detail/alkelkiiomnmjiajjcecjeicmhfhconb

More detail and pricing:
https://flinthive.com/formforge

Free tier has no daily limit, no account and no card. It runs entirely locally — no server, no telemetry, no AI, and zero standing host permissions.

But the native-setter trick above is the useful part whether or not you ever install anything. It is the single fix that solves the most common form-scripting bug in React, and it took me far too long to find.

If you know a form that breaks any of this, I would genuinely like to hear about it.

I built 125+ free calculators with React + TanStack Router on Cloudflare Pages — here's what I learned

Arafat — Mon, 06 Jul 2026 08:33:43 +0000

A few months ago I set out to build something simple: a collection of free, useful calculators that anyone could use without signing up or dealing with ads.

That turned into freefixo.com — 125+ calculators covering finance, health, legal, and travel. Here's the stack I used and what surprised me along the way.

The Stack

React (Vite) — component-per-calculator approach kept things modular
TanStack Router — file-based routing made adding new calculators trivially easy. Each new tool = one new file.
Cloudflare Pages — free tier, global CDN, deploys in ~30 seconds from a git push. Zero config for a CSR SPA.
Tailwind CSS — rapid styling without a separate stylesheet per component

No backend. No database. Everything runs client-side.

Why TanStack Router over React Router?

I wanted type-safe routes from day one. TanStack Router's file-based routing + full TypeScript inference meant I never had a mistyped route string again. The tradeoff: slightly steeper learning curve for the search param handling, but worth it.

Cloudflare Pages for a CSR SPA

One gotcha: Cloudflare Pages serves a 404 for direct URL hits on client-side routes unless you add a _redirects file:

/* /index.html 200

That one line fixes SPA routing entirely. Took me embarrassingly long to figure out.

Scaling to 125+ calculators without losing my mind

The key was a consistent pattern: every calculator is a self-contained React component that receives no props from outside — all state is local. This meant I could build, test, and ship each one independently without touching anything else.

I also built a simple JSON config file that drives the homepage grid, search, and category filters. Adding a new calculator = add the component + one line in the config.

What I'd do differently

Add meta tags earlier. I retrofitted per-page <title> and <description> tags after launch. Should've done this from calculator #1.
Build the search first. Users immediately want to search. I built it as an afterthought.
Don't wait for perfection. I had 40 calculators ready weeks before I launched. Ship earlier, iterate publicly.

The result

Live at https://freefixo.com — no signup, no ads, just tools.

Would love feedback from the DEV community, especially on the tech choices. Anyone else using TanStack Router in production? How are you handling SEO for CSR apps on Cloudflare Pages?

I Built a Free All-in-One Tool Website with 70+ Tools — Here's the Story

Arafat — Wed, 11 Mar 2026 05:50:32 +0000

Why I Built FixFlowHub

I was constantly frustrated switching between different websites
for simple tasks:

Compress an image → TinyPNG
Merge a PDF → SmallPDF (with watermark 😤)
Check grammar → Grammarly (paid)
Generate a QR code → some random sketchy site

Most tools either require sign-up, add watermarks, or lock
basic features behind a paywall.

So I decided to build one place where everything is actually free.

What I Built

FixFlowHub — a free all-in-one
online toolbox with 70+ tools across 5 categories.

🖼️ Image Tools (23 tools)

Compress images without quality loss
Convert between JPG, PNG, WebP, HEIC, AVIF, SVG, BMP, TIFF, ICO
Resize, crop, rotate, flip, watermark
Grayscale converter, image editor
Image to Base64 encoder

📄 PDF Tools (8 tools)

Merge multiple PDFs into one
Split PDF into pages
Compress PDF size
Convert PDF to image & image to PDF
Lock/unlock PDF with password
Reorder PDF pages

🤖 AI Text Tools (11 tools)

Resume builder
Cover letter generator
Grammar checker
Text rewriter & paraphraser
Email writer
LinkedIn profile generator
YouTube SEO generator
SEO tag generator
AI text summarizer
Business slogan generator
Product description generator

🧮 Calculator Tools (15 tools)

Loan EMI calculator
BMI calculator
Age calculator
Compound interest calculator
GPA calculator
Calorie calculator
Pregnancy due date calculator
Currency converter
Salary calculator
And more...

🛠️ Utility Tools (10 tools)

QR code generator
Password generator
JSON formatter & validator
Lorem ipsum generator
Color picker (HEX, RGB, HSL)
Time zone converter
Case converter
Text cleaner
HTML entities encoder
YouTube thumbnail downloader

Tech Stack

Frontend: React + Vite
Styling: Tailwind CSS
Image Processing: HTML5 Canvas API (client-side)
PDF Processing: PDF.js
AI Tools: Anthropic Claude API
Hosting: Lovable + Custom domain

Key Design Decisions

Privacy First: All image and PDF processing happens
in the browser. Files are never uploaded to any server.

No Sign-Up: I wanted zero friction. Open the tool,
use it, done.

No Watermarks: Every tool is fully functional for free.

What I Learned

Building is the easy part — getting traffic is hard 😅
SEO takes time — don't expect results overnight
People appreciate simplicity — no popups, no forced sign-ups, just working tools
Free tools attract users — but monetization needs thought

Try It Out

👉 fixflowhub.com

Would love your feedback! What tools should I add next?
Drop a comment below 👇