Load testing is only as good as your test data.
If you’re using ${__Random(1000,9999)} to simulate credit card numbers or bank account IDs in JMeter, you’re not really testing your system — you’re testing it with data that will fail validation before it even reaches your business logic.
Mock Jutsu is a free, zero-dependency JMeter custom functions plugin that generates algorithmically correct mock data directly in your test plans. No scripts, no preprocessing, no external services.
The Problem With Random Test Data
Most JMeter setups generate test data like this:
Credit card: ${__Random(1000000000000000,9999999999999999)}
IBAN: TR${__Random(10,99)}0001234567890123456789
SSN: ${__Random(100000000,999999999)}
Enter fullscreen mode Exit fullscreen mode
These values look real but fail immediately at:
- Luhn checksum validation (credit cards)
- MOD-97 validation (IBAN)
- Format and checksum rules (SSN, TCKN, NIN…)
Your backend rejects them before they touch the database. You’re load testing your validation layer, not your system.
Enter Mock Jutsu
Mock Jutsu generates data that passes real validation rules:
${__mockjutsu_financial(iban|TR)} → TR330006100519786457841326 (MOD-97 valid)
${__mockjutsu_financial(cardnum)} → 4532015112830366 (Luhn valid)
${__mockjutsu_identity(tckn|TR)} → 34521678902 (weighted checksum valid)
${__mockjutsu_identity(ssn|US)} → 532-88-4071 (format valid)
${__mockjutsu_banking(swift|TR)} → AKBKTRIS (ISO 9362 valid)
Enter fullscreen mode Exit fullscreen mode
Installation
Option 1 — JMeter Plugins Manager (recommended)
- Install Plugins Manager if you haven’t already
- In JMeter, open Options → Plugins Manager → Available Plugins
- Search for “Mock Jutsu”, check it, and click Apply Changes and Restart JMeter
Official Plugin Page: https://jmeter-plugins.org/?search=mock-jutsu
Option 2 — Manual JAR
- Download
mock-jutsu-jmeter-1.1.1.jarfrom GitHub Releases - Copy to
$JMETER_HOME/lib/ext/ - Restart JMeter
- Open Options → Function Helper Dialog — search for “mockjutsu”
Usage
In any JMeter sampler, config element, or HTTP request body:
{
"citizenId": "${__mockjutsu_identity(tckn|TR)}",
"iban": "${__mockjutsu_financial(iban|TR)}",
"cardNumber": "${__mockjutsu_financial(cardnum:visa|TR)}",
"requestId": "${__mockjutsu_meta(uuid)}"
}
Enter fullscreen mode Exit fullscreen mode
Syntax:
${__mockjutsu_<category>(type[:qualifier][|locale][|varName][|mask])}
Enter fullscreen mode Exit fullscreen mode
Examples:
${__mockjutsu_financial(cardnum)} → 4532015112830366
${__mockjutsu_financial(cardnum:visa|mask)} → 4532 01** **** 0366 (PCI DSS masked)
${__mockjutsu_financial(cardnum:visa|TR|myCard)} → stores result in ${myCard}
${__mockjutsu_meta(reverse_regex:[A-Z]{3}d{4})} → XKM7291
Enter fullscreen mode Exit fullscreen mode
Groovy / JSR223 Sampler — Direct Java API
All 390+ types are also callable directly from a JSR223 Sampler (Groovy) without the ${__mockjutsu_xxx} expression syntax, using MockJutsuRegistry as the single entry point:
import com.mockjutsu.jmeter.MockJutsuRegistry
import com.mockjutsu.jmeter.MaskerUtil
// Basic: type + locale
def citizenId = MockJutsuRegistry.generate("tckn", "TR")
def iban = MockJutsuRegistry.generate("iban", "TR")
def cardNum = MockJutsuRegistry.generate("cardnum", "TR", "visa") // with qualifier
def requestId = MockJutsuRegistry.generate("uuid", "")
// Store in JMeter variables for use in downstream samplers
vars.put("citizenId", citizenId)
vars.put("iban", iban)
vars.put("cardNumber", cardNum)
vars.put("requestId", requestId)
// Build inline JSON body
def body = """{
"citizenId": "${citizenId}",
"iban": "${iban}",
"cardNumber": "${cardNum}",
"requestId": "${requestId}"
}"""
vars.put("requestBody", body)
// Masking (PCI / GDPR)
def maskedIban = MaskerUtil.mask("iban", iban)
vars.put("ibanMasked", maskedIban)
Enter fullscreen mode Exit fullscreen mode
Use the Java API when you need runtime flexibility — loops, conditionals, or dynamic type selection — that the expression syntax cannot provide.
Generate Any Custom Format With reverse_regex
Not every field maps to a known type like IBAN or SSN. Every system has its own internal IDs, reference numbers, and codes — and they all have a format your API enforces. This is where reverse_regex comes in.
Instead of generating a constant like “ORD-00000001” across all 500 threads, reverse_regex generates a unique, format-compliant value per request:
${__mockjutsu_meta(reverse_regex:ORD-d{8})} → ORD-47291830
${__mockjutsu_meta(reverse_regex:TXN[A-Z]{2}d{10})} → TXNQR8471920384
${__mockjutsu_meta(reverse_regex:REF-[A-Z]{3}-d{6})} → REF-KWP-029471
${__mockjutsu_meta(reverse_regex:[A-Z0-9]{12})} → X7K2M9QR4LPT
${__mockjutsu_meta(reverse_regex:d{4}/d{2}/d{2})} → 2026/08/07
Enter fullscreen mode Exit fullscreen mode
This matters because many systems deduplicate on these reference fields. If every thread sends the same hardcoded order ID, your test hits duplicate-key errors — and you’re not testing throughput, you’re testing your dedup logic.
In Groovy, the regex is passed as the qualifier:
import com.mockjutsu.jmeter.MockJutsuRegistry
def orderId = MockJutsuRegistry.generate("reverse_regex", "", "ORD-\d{8}")
def txnRef = MockJutsuRegistry.generate("reverse_regex", "", "TXN[A-Z]{2}\d{10}")
def batchRef = MockJutsuRegistry.generate("reverse_regex", "", "BATCH-[A-Z0-9]{6}")
vars.put("orderId", orderId)
vars.put("txnRef", txnRef)
vars.put("batchRef", batchRef)
Enter fullscreen mode Exit fullscreen mode
No other JMeter function handles this in a single expression. The closest alternative is a BeanShell script with a custom regex library — that’s a dependency, a script file, and 20 lines of boilerplate. reverse_regex does it in one line, zero dependencies.
Supported Data Types (390+)
Category Examples Identity TCKN, SSN, NIN, INN, de_idnr, SIRET, br_cpf, in_aadhaar… Financial IBAN, credit cards (Visa/MC/Amex/Mir), CVV, PIN, SEPA QR Banking SWIFT/BIC, routing number, MT940, CAMT053, MICR line Payments SWIFT MT103, PAIN001, NACHA ACH, SEPA mandate, Fedwire Health FHIR patient, NHS number, ICD-10, HL7 message, NPI Capital Markets ISIN, CUSIP, SEDOL, LEI, FIX message, FX pair Crypto BTC address, ETH address, tx hash, mnemonic, NFT token MRZ Passport TD3, TD1 (ICAO Doc 9303 valid) IoT / RFID / NFC RFID UID, NFC tag, MQTT payload, LoRa packet Location Latitude, longitude, coordinates, timezone Meta UUID, JWT, Bearer token, IP, MAC address, reverse_regex Telecom IMEI (Luhn), ICCID, IMSI, MSISDN Security X.509 cert, CEF log, PCAP hex, CVE ID Compliance AML risk, KYC doc type, SAR number, PEP statusFull list: https://altansayan.github.io/mock-jutsu-api/
Why Zero Dependencies Matters
The JAR has no runtime dependencies. Drop it in lib/ext/ and it works.
No classpath conflicts, no version hell, no corporate proxy issues downloading transitive dependencies.
Algorithm Guarantees
All generated data passes real checksum and format validation:
Type Algorithm TCKN d9/d10 Turkish checksum IBAN MOD-97 (ISO 13616) Card numbers Luhn IMEI Luhn NHS Number Modulo 11 EAN-13/8 GS1 checksum ISIN Luhn (alphanumeric) MRZ ICAO Doc 9303 composite check digit BTC Address Base58Check (SHA256d) ETH Address Keccak-256 EIP-55 LEI MOD-97 (ISO 17442)Real-World Use Case: Fintech Load Test
Testing a payment API that validates IBAN + card number combinations:
Thread Group: 500 users, 60s ramp-up
HTTP Request — POST /api/payment
Body:
{
"sourceIban": "${__mockjutsu_financial(iban|TR)}",
"cardNumber": "${__mockjutsu_financial(cardnum:visa|TR)}",
"cvv": "${__mockjutsu_financial(cvv3)}",
"amount": "${__Random(100,10000)}",
"currency": "TRY",
"requestId": "${__mockjutsu_meta(uuid)}"
}
Enter fullscreen mode Exit fullscreen mode
Every request generates a unique, format-valid payload that passes validation and actually reaches your payment processing logic. That’s the load test that matters.
Performance
347 of 423 types (82%) average under 0.05 ms at 1,000 concurrent threads. Only 5 types exceed 0.15 ms (OIDC, AI, Prometheus) — pre-generate these via CSV for production load tests.
답글 남기기