Dev
Mock WebSocket Message Generator
Building real-time features without a live WebSocket server means your handler tests, Storybook stories, and mock configs all need realistic JSON payloads to develop against. A mock WebSocket message generator produces domain-specific JSON for five event categories — chat, trading, IoT, notifications, and gaming — with randomized field values on every run. The `eventType` input controls the message schema. Chat messages cover message.sent and user.typing events with roomId, userId, text, and timestamp. Trading messages include price.update and order.filled with symbol, price (float), and orderId. IoT messages carry deviceId, sensor type, numeric value, and unit. Notifications include type, message text, and a read boolean for badge logic. Gaming messages carry playerId, x/y coordinates, score, and level. The `count` input generates 1 to 15 messages.
How to use
- Choose your options above
- Click Generate
- Copy your result
Detailed instructions
- Select the Event Domain that matches your application — chat, trading, notification, IoT, or gaming.
- Set the Number of Messages to how many payloads your test or prototype needs (start with 4).
- Click Generate to produce the JSON message array in the output panel.
- Copy the output and paste it into your test fixture file, mock server handler, or component story.
- Edit field names or values as needed to align with your specific API schema before committing.
Use Cases
- •Feeding Jest or Vitest unit tests for a Redux WebSocket middleware without spinning up a live server
- •Seeding a Storybook story with a realistic stream of trading or chat messages as component args
- •Replaying generated IoT sensor payloads through MSW's WebSocket interceptor to stress-test a monitoring dashboard
- •Demoing a real-time trading UI to stakeholders using generated ticker events instead of a live feed
- •Populating a socket.io-mock handler with gaming events to test player-action rendering logic
Tips
- →Generate a batch of 8 or more messages and feed them with `setInterval` to simulate a realistic message stream velocity rather than a static snapshot.
- →For trading domain tests, look for the price and direction fields — run several generations and pick payloads with both upward and downward moves to test your colour-coding logic.
- →Combine the IoT domain output with a chart library like Recharts by mapping each payload's value and timestamp into a data array — instant live-data demo with zero backend.
- →When testing chat UIs, manually edit one generated message to be 300+ characters to confirm your message bubble layout handles long text without breaking.
- →Paste multiple generations back-to-back into one array to build a larger fixture set that covers more variance without running the generator dozens of times.
- →Use the notification domain payloads to test unread badge counts — the `read` boolean field lets you mix seen and unseen states in a single fixture array.
FAQ
how do I test websocket message handlers without a running server
Copy the generated JSON and pass each object directly to your handler function in a unit test — no connection needed. For integration-level tests, mock-socket or MSW's WebSocket interceptor let you replay the payloads through the actual WebSocket API so your component behaves as if a live server sent the data, without standing up a real server.
are randomly generated websocket payloads reliable enough for a real test suite
For handler and rendering tests, yes. Each run produces different timestamps, prices, and sensor readings, which surfaces edge cases — long strings, unexpected value ranges, unusual event types — that a fixed fixture would never expose. If your tests must be deterministic, generate one batch, review it, and commit it as a static fixture file rather than regenerating on each test run.
what is the difference between the five event domains in the generator
Each domain produces field names and value ranges specific to that use case: chat includes sender IDs and room IDs, trading includes ticker symbols and price floats, IoT includes sensor type and physical unit strings, notifications include a read boolean for badge logic, and gaming includes x/y coordinates and score integers. Pick the domain closest to your application's WebSocket contract to minimize the field renaming needed.
what does the message structure look like across all domains
Every generated message is a JSON object with two top-level keys: type (a domain-specific event string like 'message.sent' or 'price.update') and payload (a nested object with domain-specific fields). The consistent envelope structure means your WebSocket message dispatcher can route by type regardless of which domain you're testing.
You might also like
Popular tools from other categories that share themes with this one.
Try these next
More free tools from other corners of the catalog, picked by shared themes.