I Tested TestSprite on an Indonesian SaaS App — Here's What the AI Missed (and Caught)

Tandjiro — Sun, 03 May 2026 19:39:27 +0000

We've had the same conversation every sprint: QA flags a localization bug two days before deployment, someone hard-fixes it, and two weeks later a different locale breaks the same component. Sound familiar?

I decided to run TestSprite 2.1 on one of our production-grade web apps — a B2B SaaS billing and scheduling platform serving Indonesian SMEs. The app handles IDR payments, WIB/WITA/WIT timezone display, and Bahasa Indonesia UI strings. This is exactly the kind of locale-heavy codebase that breaks testing tools not built with non-US markets in mind.

Here's an honest account of what happened.

Setup: Faster Than I Expected

TestSprite 2.1 installs as an npm package and connects to your staging environment via a config file. I had it running against our Next.js frontend in under 15 minutes:

npm install testsprite --save-dev
npx testsprite init
npx testsprite crawl --url https://staging.yourapp.com --locale id-ID

Within one crawling session (~18 minutes), TestSprite identified 52 unique user flows — login, invoice generation, subscription management, appointment scheduling, and payment confirmation. All automatically converted into runnable test cases, zero manual writing.

TestSprite 2.1's new AI engine is noticeably faster than previous versions. Our full test suite ran in about 6 minutes. For context, our old Playwright setup takes 22 minutes for the same coverage.

Locale Observation #1: IDR Currency Parsing Is Broken Out of the Box

This is the most critical issue for any developer building fintech or e-commerce apps in Indonesia.

The Indonesian Rupiah format: Rp 1.500.000 (period = thousands separator, no decimals)What TestSprite parsed it as: 1.5 (treating the period as a decimal point)

When TestSprite crawled our invoice page, it extracted Rp 1.500.000 from the DOM and created assertions based on the value 1.5. Every price-related test then failed — not because our app was broken, but because TestSprite's number parser assumes the US convention (comma = thousands, period = decimal).

The downstream effect: our checkout flow tests showed 100% failure rate on first run. It looked catastrophic. In reality, the app was working perfectly.

Root cause: TestSprite defaults to en-US number parsing unless you explicitly configure locale. The locale flag in the CLI changes display locale but doesn't fully propagate to the value extraction layer — at least in our testing.

Workaround that worked for us:

// testsprite.config.js
module.exports = {
locale: 'id-ID',
numberFormat: {
thousandsSeparator: '.',
decimalSeparator: ',',
currencySymbol: 'Rp',
currencyPosition: 'prefix'
}
}

After adding this, price assertions became accurate. But this config option is not documented in the main quickstart guide — I found it buried in a GitHub issue. For Indonesian developers, this is a must-know before your first run.

Locale Observation #2: Timezone Ambiguity — WIB, WITA, WIT

Indonesia spans three time zones: WIB (UTC+7), WITA (UTC+8), and WIT (UTC+9). Our scheduling app shows appointment times localized to each user's timezone, with the abbreviation displayed next to the time.

TestSprite flagged every single timezone label as a failed assertion. Why? It couldn't recognize WIB, WITA, or WIT as valid timezone identifiers. It expected IANA-standard zone names like Asia/Jakarta or UTC offset notation like +07:00.

Example failure:

Expected: "14:30 WIB"
Received: "14:30 WIB"

Status: FAIL — unrecognized timezone identifier

Yes — the strings were identical, but TestSprite's timezone validator rejected WIB as unknown.

This is a real gap. Regional timezone abbreviations like WIB, IST (India), or PST (Philippines Standard Time) are widely used in local UIs but not recognized by most IANA-based validators. For Indonesian apps, this generates a flood of false-positive failures that you have to manually whitelist.

Fix: We added a custom timezone alias map in config and switched our UI to display 07:00 WIB (UTC+7) format — which also improved clarity for our users.
What TestSprite Got Right: Non-ASCII & Bahasa Indonesia Text

On the positive side, TestSprite handled Bahasa Indonesia strings extremely well. Our UI includes characters like é (in proper nouns), ñ (for some partner brand names), and Indonesian-specific punctuation patterns. TestSprite generated correct assertions for all of these without encoding issues.

It also caught 4 hardcoded Indonesian strings that should have been externalized to our i18n config but were left as raw text in JSX components — something our own code review had missed. These would've broken our planned English-language version of the app.

The Verdict

Aspect

Rating

Setup speed

⭐️⭐️⭐️⭐️⭐️

Test generation quality

⭐️⭐️⭐️⭐️

IDR currency handling (default)

⭐️⭐️

Timezone support for non-IANA abbreviations

⭐️⭐️

Non-ASCII / Bahasa Indonesia text

⭐️⭐️⭐️⭐️⭐️

CI/CD integration

⭐️⭐️⭐️⭐️

Documentation for non-US locales

⭐️⭐️⭐️

Overall: 7.5/10 for Indonesian-market apps.

TestSprite 2.1 is a genuinely powerful tool. The AI-generated test coverage is impressive, and the self-healing test engine (which auto-updates tests when your UI changes) alone is worth the price for teams tired of maintaining brittle Playwright suites.

But if you're building for Indonesia — or any market outside the US/EU mainstream — plan for an extra half-day of locale configuration work before your first real test run. The defaults will mislead you.

Once configured correctly, though, it caught bugs we'd have missed for months. The IDR parsing issue it surfaced (after we understood the false positives) revealed an actual bug in how we handled rounding for installment payments. That alone saved us from a nasty production incident.

Stack: Next.js 14, TypeScript, Prisma, deployed on VercelTestSprite version: 2.1Locales tested: id-ID, en-USTest runtime: ~6 minutes (52 user flows)

💡 TL;DR for Indonesian devs: Add explicit numberFormat config for IDR before your first crawl. Don't let the false positives on currency tests scare you off — the tool is solid once tuned.

DEV Community: Tandjiro

I Tested TestSprite on an Indonesian SaaS App — Here's What the AI Missed (and Caught)