Coder Legion - Recent posts tagged apitesting

The fastest way I know to poke an endpoint

Mon, 06 Jul 2026 09:27:20 +0000

Most of my API checks are embarrassingly small. Is staging up? Does this endpoint still return the field the frontend expects? Did the auth header fix actually deploy? For work that small, opening Postman feels like bringing a truck to carry one grocery bag, and curl means fifteen seconds of remembering whether it's -H or -d that wants the quotes.

So this lives in a browser tab now: catssaymeow.org/api-client

Pick a method, paste a URL, add headers and a body if the call needs them, send. The response comes back as one readable unit: status code, timing, headers, and body, with the JSON already pretty-printed. Nothing to install, no account, no workspace to name.

One detail that earns its keep: the URL field also accepts a full cURL string. Copy a request out of a bug ticket or a browser's "Copy as cURL", paste it in, and the method, headers, and body populate themselves.

The part I actually built it for

Half the time someone wants to try an API tool, they don't have an endpoint handy. Staging is down, the ticket hasn't landed, or they're teaching someone what a 401 even is.

The Practice API covers that case. It's a mock REST API that runs client-side in the page, with seeded /users and /posts collections and one-click examples grouped by intent: read, write, delete, meta.

The examples aren't just happy paths. There's a 404 for a missing record, a 401 for a protected route without a token, a 204 with no body, an OPTIONS preflight. Every status a junior tester will meet in their first month, reproducible on demand.

And the mock is stateful within the page. POST a new user, then GET the collection, and the new record is there:

That's the difference between a demo and a practice environment. Reloading the page resets everything, so there's nothing to clean up and no way to break it for the next person.

The boring but important part

Real requests route through a server-side proxy with layered SSRF protections, rate limiting, and per-host circuit breakers, so the tool can't be pointed at internal infrastructure. Practice API requests never touch the network at all; the responses are generated in the page, and the response panel labels them "Simulated" so there's no confusion about what was real.

It works on a phone, too, which has saved me at least once when a deploy check couldn't wait for a laptop.

If a quick endpoint check is on today's list, it's at catssaymeow.org/api-client. Free, no signup, and the Practice API is there when the real endpoint isn't.

I Was Tired of Installing API Tools Just to Test One Endpoint — So I Found Something Better

Wed, 03 Jun 2026 18:41:12 +0000

Let me paint you a picture.

It's 11 PM. You're integrating a third-party payment API into your app. The documentation is decent, but something isn't working — you keep getting a 401 Unauthorized back, and you have no idea if it's your token, your headers, or just the universe conspiring against you.

Your options? Fire up Postman (which you haven't opened in three weeks and now wants to update), install Insomnia (if you remember your account password), or try writing a quick curl command in the terminal — knowing full well you'll mess up the escaping on the JSON body and spend another 20 minutes Googling why.

There's a fourth option. One that requires zero installs, zero accounts, and zero patience for setup.

But before we get there — let's actually talk about REST APIs, because if you're new to this world, a lot of it can feel unnecessarily mysterious.

What Even Is a REST API?

Here's the non-textbook version: a REST API is just a way for two systems to talk to each other over the internet using standard web rules.

When you open Instagram and your feed loads — that's your app making an API call to Instagram's servers. When you book a flight and your seat gets confirmed — that's an API call going to the airline's backend. When Slack notifies you of a new message on your phone — you guessed it.

REST stands for Representational State Transfer, which sounds incredibly academic and not particularly useful to know. What matters is the practical part: REST APIs use regular HTTP (the same protocol your browser uses), they deal in resources (think: users, orders, products), and they communicate mostly in JSON — a format that looks like this:

{
  "user": "sadiq",
  "status": "active",
  "plan": "pro"
}

Clean. Human-readable. Easy to work with.

The other thing you need to know is that REST APIs use HTTP methods to express intent:

GET — "Give me something." Fetching a list of users, loading a profile, retrieving an order.
POST — "Create something new." Submitting a form, registering an account, placing an order.
PUT — "Replace this thing entirely." Updating a user's full profile.
PATCH — "Just change this one part." Updating only the email address on a profile.
DELETE — "Get rid of this." Removing a record.

These five methods cover about 99% of what you'll encounter in real-world API work. The other two — HEAD and OPTIONS — are more behind-the-scenes, usually used for checking if a resource exists or for CORS preflight checks.

The Problem With Testing APIs

Here's something nobody talks about enough: testing APIs is just hard enough to be annoying.

It's not hard like writing a compiler or implementing a sorting algorithm. It's hard in a friction-filled, setup-heavy, "why am I spending 20 minutes on this" kind of way.

If you're a backend developer, you probably have curl muscle memory by now. But curl is unforgiving — one misplaced quote or escaped character and your beautifully crafted JSON body turns into garbage. And reading curl output when something goes wrong? Not exactly a pleasant experience.

Postman is the gold standard for a lot of teams, and for good reason — it's powerful. But powerful also means complex. Collections, environments, workspaces, team sync — it's a lot when you just want to fire off a quick request to see if an endpoint returns what it's supposed to. There's also the matter of it being a desktop app you need to install, update, and sometimes log into.

The other issue that catches developers off-guard — especially those newer to frontend work — is CORS.

CORS (Cross-Origin Resource Sharing) is a browser security feature that blocks your JavaScript from calling APIs on different domains unless the API explicitly says "yes, this domain can talk to me." It exists for genuinely good reasons (preventing malicious websites from making requests on your behalf), but it's also the source of an enormous amount of confusion and pain.

You'll write what looks like perfect code. You'll test it. You'll get a wall of red text in your browser console that says something like Access to fetch at 'https://api.example.com' from origin 'http://localhost:3000' has been blocked by CORS policy. And you'll wonder if you've done something horribly wrong.

You haven't. The API just doesn't allow browser-based requests from your origin. It'll work fine server-to-server — which is exactly why a server-side testing tool is so much more useful than a browser-based one.

Meet the Tool That Actually Fixes This

There's a free online REST API tester over at sadiqbd.com — specifically the REST API Checker — and honestly, it's become one of those tools I didn't know I needed until I started using it.

The concept is simple: you paste in your API URL, choose your method, add any headers or a request body, and hit Send. Within seconds you get back the full response — status code, response headers, response body (pretty-printed if it's JSON), and the time it took.

What makes it different from just opening your browser's Network tab is the server-side proxying. When you use this tool, the request doesn't come from your browser — it comes from their server. That completely bypasses CORS. It doesn't matter if the API has restrictive CORS headers or none at all. You'll get the real response, every time.

Let me walk through what it actually supports:

HTTP Methods: GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS. Every method you'll realistically need.

Custom Headers: Add as many as you need. Authorization tokens, Content-Type overrides, custom API keys — any header the API expects, you can set it. The Authorization header field especially comes in handy when you're debugging authentication: Bearer your-token-here goes in just like you'd set it in code.

Request Body Formats: Three options — JSON (which auto-sets Content-Type: application/json), raw (for XML, plain text, or anything else), and multipart form-data (for file uploads). This is actually comprehensive enough to cover most real-world API testing scenarios.

Response Details: You get the status code, response time, body size, all response headers, and the formatted body. If the API returns JSON, it's automatically prettified so you can actually read it.

Real Scenarios Where This Saves Time

Scenario 1: You're integrating a new API and want to verify it works before writing any code.

This is the fastest use case. Copy the example request from the documentation, paste it in, run it. If it returns what the docs say it should, you know the API is working and your credentials are valid. Now you can write code with confidence.

Scenario 2: Something's broken in production and you need to isolate whether it's your code or the API.

Hit the API directly from the tester with the same payload your code sends. If it works there but not in your app, the bug is in your code. If it fails there too, the API is the problem. Five seconds of testing that would have taken you 20 minutes to debug otherwise.

Scenario 3: You're getting a 400 Bad Request and have no idea why.

This is where the response body matters. Most well-designed APIs return a JSON error object explaining what went wrong — missing field, wrong data type, invalid value. The pretty-printed response makes this readable immediately. Common culprits: missing required fields, wrong data types, or subtly malformed JSON (a trailing comma that's valid in JavaScript but not in strict JSON parsers).

Scenario 4: You're testing a webhook.

Webhooks are notoriously painful to debug. With this tool, you can replay a webhook payload to your endpoint and see exactly what it returns — useful for reproducing intermittent failures or testing your error handling.

Scenario 5: Comparing staging vs. production.

Swap the URL, keep everything else the same. If staging returns something different from production, you've found your environment drift. This kind of quick comparison is surprisingly hard to do cleanly with other tools.

A Few Things Worth Knowing

On API key safety: The tool doesn't store your request bodies, headers, or responses. That said, for genuinely sensitive production credentials — the ones that control real money or user data — it's wise to use scoped test keys or short-lived tokens. Not because this tool is untrustworthy, but because that's just good security hygiene regardless of what tool you're using.

On private/internal APIs: Since requests are made server-side, they need to reach a publicly accessible URL. Private IPs and loopback addresses (localhost, 192.168.x.x, etc.) are blocked for security reasons. For internal APIs, you'd need a tunneling tool like ngrok to expose them temporarily.

On file uploads: The multipart form-data option supports file attachments up to 5 MB each. That covers most practical file upload API testing scenarios — image upload endpoints, document imports, that kind of thing.

Beyond REST API Testing

While you're on sadiqbd.com, it's worth knowing the site is actually a full toolkit for developers and beyond. The developer section alone has a JSON Formatter (genuinely one of the most-used tools when working with APIs), a JWT Decoder (paste in any JWT and instantly see the header, payload, and expiry), a Regex Tester, Hash Generator, Base64 Encoder/Decoder, and more.

There are also internet tools for DNS lookups, SSL checking, HTTP header inspection, and port scanning — the kind of things you end up Googling every few weeks and wishing were in one place.

It's the sort of site that earns a browser bookmark pretty quickly.

The Bigger Picture

Here's what I actually think about when I look at a tool like this: the best developer tools are the ones that collapse friction.

The gap between "I want to test this API" and "I have my test result in front of me" should be as small as possible. Every minute spent setting up a client, remembering a password, updating software, or wrestling with a curl command is a minute not spent on the actual problem you're trying to solve.

The REST API Checker on sadiqbd.com doesn't do everything Postman does. It doesn't have saved collections or team collaboration or automated test suites. But it does the thing you need most of the time — send a request, see the response — with literally zero friction. Open a tab, paste a URL, click Send.

That's it.

For the quick tests, the late-night debugging sessions, the "let me just verify this works before I write the integration" moments — it's hard to beat.

Wrapping Up

REST APIs are everywhere. Understanding them — even at a surface level — makes you dramatically more effective as a developer, whether you're building backends, working on frontend integrations, or just trying to make sense of why something isn't working.

And having a fast, reliable, no-fuss way to test them? That's not a luxury. It's just practical.

Bookmark sadiqbd.com/developer/rest-api-checker. You'll use it more than you expect.

Found this useful? The full suite of developer tools — JSON formatter, JWT decoder, regex tester, and more — lives at sadiqbd.com.

I Built a Free JSON Karate DSL Schema Generator for QA Engineers

Sun, 10 May 2026 18:34:28 +0000

If you work with Karate DSL for API testing, you already know how important and useful schema validation can be.

You also know how repetitive it becomes.

Writing Karate match schemas manually for every API response is one of those tasks that feels small at first until you start working with:

deeply nested JSON responses
arrays of objects
large payloads
optional fields
multiple endpoints

After doing this repeatedly in real automation projects, I decided to build a small utility focused on solving exactly that problem.

So I created a free browser-based tool:

JSON → Karate DSL Schema Converter

https://jsonkaratedslgenerator.codeqazone.com/

The tool instantly converts a JSON payload into a ready-to-use Karate DSL schema.

The Problem

Karate DSL does not use traditional JSON Schema syntax.

Instead, it uses type matchers like:

"#string"
"#number"
"#boolean"
"#[]"
"##string"

That approach is powerful and very readable once you understand it.

But manually transforming a real API response into a Karate validation schema can become repetitive and time-consuming.

For example, a response like this:

{
  "id": 101,
  "name": "Alice",
  "active": true,
  "roles": ["admin", "user"]
}

Usually becomes something like:

{
  "id": "#number",
  "name": "#string",
  "active": "#boolean",
  "roles": "#[] #string"
}

And that is a very small example.

In real-world APIs, payloads can be much larger and more nested.

What the Tool Does

The converter takes a JSON payload and automatically generates a Karate-compatible schema while preserving the original structure.

It supports:

primitive types
nested objects
arrays
arrays of objects
nested arrays
optional fields
copy to clipboard
schema download

Everything runs directly in the browser.

No installation.
No backend.
No data storage.

Just paste your JSON and generate the schema instantly.

Example Conversion

Input JSON

{
  "id": 101,
  "name": "Alice",
  "active": true,
  "user": {
    "email": "*Emails are not allowed*",
    "profile": {
      "age": 30,
      "verified": true
    }
  },
  "orders": [
    {
      "orderId": 1,
      "amount": 99.99
    }
  ]
}

Generated Karate Schema

{
  "id": "#number",
  "name": "#string",
  "active": "#boolean",
  "user": {
    "email": "#string",
    "profile": {
      "age": "#number",
      "verified": "#boolean"
    }
  },
  "orders": "#[] {\"orderId\":\"#number\",\"amount\":\"#number\"}"
}

Required vs Optional Fields

One thing I intentionally wanted in the tool was explicit control over required and optional fields in the schema.

Instead of automatically guessing business rules, the tool lets the tester define which fields are required.

Example:

id, name, user.email

Fields included in that input remain required while all other fields are automatically converted into optional Karate matchers using the ## syntax.

That decision came directly from real QA workflows.

As testers, we usually already know:

which fields are mandatory
which fields are conditional
which fields depend on business logic

The tool is not trying to replace that understanding, it is simply removing the repetitive manual work.

Why I Built It

This project came from real automation work. The goal was not to create a massive platform, it was to create something:

fast
practical
useful immediately
frictionless to use

A tool you can open, use in seconds, and continue with your work.

Features

Current features include:

JSON → Karate DSL conversion
Required fields input
Optional field generation (##type)
Nested object support
Array schema generation
Demo examples
Copy-to-clipboard support
Schema download
Browser-only execution

Who Is This For?

This tool is especially useful for:

QA Automation Engineers
API Testers
Developers using Karate DSL
Teams building API validation suites
People learning Karate schema validation

Try It

https://jsonkaratedslgenerator.codeqazone.com/

The app also includes:

Base Demo
Advanced Demo

so you can immediately understand how the conversion works.

If you work with Karate DSL, I hope this tool saves you some time. Feedback and suggestions are always welcome.

Happy Testing!

Voiden: curl meets Obsidian

Fri, 17 Apr 2026 11:07:47 +0000

We open sourced Voiden: an offline API tool where requests live as executable Markdown and are versioned in Git. Its built on Electron and its free.

The original idea and inspiration is to combine the flexibility of Obsidian-style files or Jupyter notebooks with the practicality of curl. Instead of static API request forms, everything in the tool is composed with blocks (endpoint, auth, params, body) that can be added, reused, overridden, and stitched together across plain text markdown files.

Since Open Sourcing, we got 11K installs, a lot of feedback and some committed and opinionated contributors.

A few highlights:

Programmable UI: Building API requests with blocks using slash commands (endpoints, headers, auth, params, etc.).
Reusable blocks: These blocks can be connected to (and reused by) multiple docs. Change a value once, update everywhere. Just like in code when we add an extra logic to an imported method. (In other API clients you would need to duplicate stuff or just use environment variables to substitute.)
Specs, tests, and docs live together in executable Markdown . You can structure APIs, tests, and docs however you want and everything stays executable/runnable in the same place.
Scripting: We have seen other API tools locking scripts into a constrained JS runtime. Voiden runs locally, that means you can use whatever is already on your machine (Node, Python, shell, etc.). So this feels like real scripting and not sandboxes.
Multiple requests per file (mini workflows): Putting multiple requests in a single .void file turned out to be surprisingly useful. You can group full flows together (create-pay-confirm), or full CRUD cycles. The file becomes an executable workflow where docs and tests live together naturally, and you can run one request or the entire sequence end-to-end.
Stitch (workflows across files): Instead of building large monolithic collections, workflows can be composed from smaller .void files. This way, Auth, setup, CRUD, etc. become pieces that can be reused and combined across contexts without duplication. This is still early and evolving.
Agents: Added “skills” so tools like Claude or Codex can work directly with .void files using your own environment and subscriptions. Yeah, one of the perks of everything being file-based and Markdown-first.
We also built an SDK for community plugins and spent time improving performance, reliability, and keyboard-first DX (Electron-based, so we have been careful there).

Happy to hear any feedback, suggestions and contributions!

Github: https://github.com/VoidenHQ/voiden
Download: https://voiden.md/download

How This Tool Improves Developer Productivity with JSON and API Workflows

Mon, 15 Dec 2025 10:12:51 +0000

JSON is the de facto data interchange format for modern web and mobile applications. However, generating, validating, and maintaining JSON structures manually can introduce friction in development workflows, particularly during rapid prototyping and API development.

Automated JSON Structure Generation

The tool converts natural-language descriptions into syntactically valid, well-structured JSON. It automatically handles:

Proper nesting of objects and arrays
List item Consistent key naming
Appropriate primitive and composite data types

This reduces human error and eliminates repetitive boilerplate.

API-Ready Response Generation

Generated output can be used directly as mock API responses. This enables frontend teams to:

Develop UI components independently of backend availability Simulate
API contracts early in the development cycle Validate response
schemas before backend implementation

This approach aligns well with contract-first and API-driven development methodologies.

Summary

By automating JSON generation and validation while supporting downstream API workflows, this tool reduces development overhead and accelerates iteration cycles, allowing engineers to focus on system design and business logic rather than data scaffolding.

Reference tool:
https://formatjsononline.com/ai-json-generator

Stop Mocking Everything: How to Test API Resilience in Your Terminal (Curl + Chaos Proxy)

Fri, 05 Dec 2025 07:15:00 +0000

"It works on my machine."

We've all said it. But does your bash script work when the third-party API takes 15 seconds to respond? Does your backend service gracefully handle a sudden spike of 503 errors from a payment provider?

Writing a full mock server just to test a simple retry logic in a script is often overkill. In this tutorial, I'll show you a faster way: Chaos Engineering directly in the terminal.

We will use curl and a cloud-based Chaos Proxy to inject failures into real network requests without changing a single line of your application code.

The Problem: Localhost is Too Perfect
When developing locally, network latency is near zero. APIs either work (200 OK) or they don't (Connection Refused). But in production, you face:

High Latency: The server is busy.
Intermittent Failures: 5% of requests drop.
Throttling: You hit the rate limit.

Simulating this in a terminal usually involves complex iptables rules or local tools like tc (Traffic Control). There is an easier way.

The Solution: Cloud Chaos Proxy
Instead of configuring your OS, we will route specific requests through a proxy that "breaks" the traffic according to rules we define.

I'll be using chaos-proxy.debuggo.app for this, but the concept applies to any programmable proxy.

Video Guide (1:27)
Prefer watching? Here is the 90-second workflow:

Step-by-Step Tutorial

1. Define the Failure
First, we need to tell the proxy what to break.

Target: httpbin.org (or your API domain).
Delay: 7 seconds (Simulate lag).
Failure Rate: 1 (100% of requests will fail).
Error Code: 503 Service Unavailable.

2. Trust the Certificate (The "One-Time" Setup)
Since we are intercepting HTTPS traffic, we need to trust the proxy's CA certificate.

Download the mitmproxy-ca-cert.pem from the dashboard.

MacOS: Add it to Keychain Access -> System and set "Always Trust".

Linux: Copy to /usr/local/share/ca-certificates/ and update.

3. The Magic Command
Now, we use curl with the -x (proxy) flag.

curl -v -x http://user:*Emails are not allowed*:13979 https://httpbin.org/get

Understanding the Output
When you run this command multiple times:

Scenario A (The Chaos): You'll notice the terminal "hangs" for 7 seconds (our delay). Then:

< HTTP/1.1 500 Internal Server Error
< content-length: 56
< content-type: text/plain
...
Debuggo Chaos Injection: 500 Error

Scenario B (Success): The other 50% of the time, the request passes through to the real server:

< HTTP/1.1 200 OK
...
{
  "args": {}, 
  "headers": { ... }
}

Real World Use Cases

Testing CI Pipelines: Verify that your deployment scripts don't crash if a dependency is slow.
Cron Jobs: Ensure your nightly data sync retries correctly on failure.
Quick Sanity Checks: Before pushing code, verify how the API client handles a 503 error.

Conclusion
You don't need heavy infrastructure to test network resilience. A simple proxy setup allows you to inject chaos into any HTTP client—be it curl, wget, or your Python/Node.js scripts.

Happy Breaking!

API Performance Testing with k6 - A Quick Start Guide

Tue, 04 Feb 2025 06:36:54 +0000

Introduction

The definition of a high-quality REST API application is an application that can operate well and perform well. The performance of the REST API can be measured by performance testing to ensure the application is operational, scalable, and reliable on many different workloads. From normal workloads up to unexpected heavy workloads.

Why Performance Testing?

The performance testing provides some benefits during REST API development:

Ensuring the performance of the REST API meets the desired standards, especially in unexpected workloads.
Detecting performance bottlenecks earlier before it went to production.

What is k6?

Many tools can be used for performance testing. One of those is k6. k6 is a performance testing tool developed by Grafana Labs for conducting performance testing in various platforms like REST API and web applications. The k6 is a code-based tool which means the testing script is written in a Javascript code. The k6 can be utilized even more by using additional plugins and extensions.

k6 Setup

These are the required steps for using k6:

Install the k6. The k6 is available in Docker container and binary. Make sure to install it based on the operating system that is being used.
Configure the code editor. The code editor needs to be configured to enable the IntelliSense feature to enhance the developer experience when writing testing scripts.

Writing the First Test

The k6 testing scripts can be organized into one project because when working in a project, the scripts can be organized easily.

Create the npm project by running this command.

npm init --yes

If you want to specify the additional information of the project, use npm init.

After that, install the k6 types to enable the IntelliSense feature.

npm install --save-dev @types/k6

The test script can be generated automatically using the k6 new command. This is the structure of the command.

k6 new <directory_name>/filename.js

Make sure the directory is exists.

If the directory location is not specified. This command creates a test script in the current working directory. The test script can be created manually as well.

This is the example of creating a new test script in the src directory.

k6 new src/test.js

This is the content of the created test script. The comments inside the test script is already removed.

import http from "k6/http";
import { sleep } from "k6";

export const options = {
  // A number specifying the number of VUs to run concurrently.
  vus: 10,
  // A string specifying the total duration of the test run.
  duration: "30s",
};

export default function () {
  http.get("https://test.k6.io");
  sleep(1);
}

The test can be executed using k6 run command followed by the file name.

k6 run src/test.js

This is the output of the test.

After the test is executed, the k6 generates a summary output that describes information like the number of successful requests, duration of the requests, and others.
A detailed explanation of the summary output is available here.

Load Testing Types

There are many types of load testing for measuring the performance of the system. Each type serves different purposes and requirements.

Smoke Testing

The smoke testing ensures the system is operational with a minimal load and verifies the test scripts. The smoke testing must be executed with a small number of virtual users (from 2 up to 5 VUs) and short duration.

This is an example of smoke testing for getting all posts feature.

import http from "k6/http";
import { check } from "k6";

export const options = {
  vus: 3, // 3 virtual users
  duration: "40s", // duration is 40 seconds
};

export default function () {
  // sends GET request
  const response = http.get("https://jsonplaceholder.typicode.com/posts");

  // validate the response
  check(response, {
    "is status 200": (r) => r.status === 200,
    "is not null": (r) => r.json() !== null,
  });
}

Average Load Testing

The average load testing ensures the system is operational with typical loads. Typical loads means the workload during the regular day in a production environment.

This is the example of average load testing for getting all posts feature.

import http from "k6/http";
import { check } from "k6";

export const options = {
  stages: [
    { duration: "5m", target: 100 }, // traffic ramp-up from 1 to 100 users over 5 minutes.
    { duration: "30m", target: 100 }, // stay at 100 users for 30 minutes
    { duration: "5m", target: 0 }, // ramp-down to 0 users
  ],
};

// function for generating random string
const generateRandomString = (start, end) => {
  const res = Math.random().toString(36).substring(start, end);
  return res;
};

// function for generating random ID
const generateRandomId = () => {
  const id = Math.floor(Math.random() * 1000);
  return id;
};

export default function () {
  // prepare request body
  const requestBody = {
    title: generateRandomString(1, 7),
    body: generateRandomString(1, 20),
    userId: generateRandomId(),
  };

  // sends POST request
  const response = http.post(
    "https://jsonplaceholder.typicode.com/posts",
    JSON.stringify(requestBody),
    {
      headers: {
        "Content-Type": "application/json",
        Accept: "application/json",
      },
    }
  );

  // validate the response
  check(response, {
    "is status 201": (r) => r.status === 201,
    "is not null": (r) => r.json() !== null,
    "is contains valid id": (r) => r.json().id > 0,
    "is contains valid title": (r) => r.json().title !== "",
    "is contains valid body": (r) => r.json().body !== "",
  });
}

Stress Testing

The stress testing ensures the system is operational with heavier loads than usual. The stress testing verifies the stability and reliability of the system under heavy workloads. The system may receive heavy workloads in many moments such as flash-sale, payday, school or university admission process, and other similar moments. When conducting the stress testing, the number of workloads must be heavier than typical workloads and must be executed after average load testing.

This is an example of stress testing for creating a new post feature.

import http from "k6/http";
import { check } from "k6";

export const options = {
  stages: [
    { duration: "10m", target: 200 }, // traffic ramp-up from 1 to a higher 200 users over 10 minutes.
    { duration: "30m", target: 200 }, // stay at higher 200 users for 30 minutes
    { duration: "5m", target: 0 }, // ramp-down to 0 users
  ],
};

// function for generating random string
const generateRandomString = (start, end) => {
  const res = Math.random().toString(36).substring(start, end);
  return res;
};

// function for generating random ID
const generateRandomId = () => {
  const id = Math.floor(Math.random() * 1000);
  return id;
};

export default function () {
  // prepare request body
  const requestBody = {
    title: generateRandomString(1, 7),
    body: generateRandomString(1, 20),
    userId: generateRandomId(),
  };

  // sends POST request
  const response = http.post(
    "https://jsonplaceholder.typicode.com/posts",
    JSON.stringify(requestBody),
    {
      headers: {
        "Content-Type": "application/json",
        Accept: "application/json",
      },
    }
  );

  // validate the response
  check(response, {
    "is status 201": (r) => r.status === 201,
    "is not null": (r) => r.json() !== null,
    "is contains valid id": (r) => r.json().id > 0,
    "is contains valid title": (r) => r.json().title !== "",
    "is contains valid body": (r) => r.json().body !== "",
  });
}

Spike Testing

The spike testing ensures the system is operational with suddenly heavy workloads. Example of sudden heavy workloads is product launch events, limited-time discount,s and others. During spike testing, the heavy workloads increased suddenly without any ramp-down or "pause time".

This is an example of spike testing for updating a post feature.

import http from "k6/http";
import { check } from "k6";

export const options = {
  stages: [
    { duration: "2m", target: 500 }, // fast ramp-up without any break
    { duration: "1m", target: 0 }, // quick ramp-down
  ],
};

// function for generating random string
const generateRandomString = (start, end) => {
  const res = Math.random().toString(36).substring(start, end);
  return res;
};

// function for generating random ID
const generateRandomId = () => {
  const id = Math.floor(Math.random() * 100);
  return id;
};

export default function () {
  const sampleId = generateRandomId();

  // prepare request body
  const requestBody = {
    title: generateRandomString(1, 7),
    body: generateRandomString(1, 20),
    userId: sampleId,
  };

  // sends PUT request
  const response = http.put(
    `https://jsonplaceholder.typicode.com/posts/${sampleId}`,
    JSON.stringify(requestBody),
    {
      headers: {
        "Content-Type": "application/json",
        Accept: "application/json",
      },
    }
  );

  // validate the response
  check(response, {
    "is status 200": (r) => r.status === 200,
    "is not null": (r) => r.json() !== null,
    "is contains valid id": (r) => r.json().id > 0,
    "is contains valid title": (r) => r.json().title !== "",
    "is contains valid body": (r) => r.json().body !== "",
  });
}

Endurance Testing

The endurance testing (also known as soak testing) ensures the system is operational with average loads for a long duration. This test measures the performance degradation and the availability and stability during long periods.

The endurance testing can be executed after the smoke and average load tests are executed. The duration of this test must be longer than any other kind of test.

Actually, the typical duration is in hours like 3,4,12 ,and up to 72 hours. For this example, the duration is reduced.

This is an example of endurance testing for creating a post feature.

import http from "k6/http";
import { check } from "k6";

export const options = {
  stages: [
    { duration: "10m", target: 100 }, // traffic ramp-up from 1 to 100 users over 10 minutes.
    { duration: "30m", target: 100 }, // stay at 100 users for 30 minutes
    { duration: "10m", target: 0 }, // ramp-down to 0 users
  ],
};

// function for generating random string
const generateRandomString = (start, end) => {
  const res = Math.random().toString(36).substring(start, end);
  return res;
};

// function for generating random ID
const generateRandomId = () => {
  const id = Math.floor(Math.random() * 1000);
  return id;
};

export default function () {
  // prepare request body
  const requestBody = {
    title: generateRandomString(1, 7),
    body: generateRandomString(1, 20),
    userId: generateRandomId(),
  };

  // sends POST request
  const response = http.post(
    "https://jsonplaceholder.typicode.com/posts",
    JSON.stringify(requestBody),
    {
      headers: {
        "Content-Type": "application/json",
        Accept: "application/json",
      },
    }
  );

  // validate the response
  check(response, {
    "is status 201": (r) => r.status === 201,
    "is not null": (r) => r.json() !== null,
    "is contains valid id": (r) => r.json().id > 0,
    "is contains valid title": (r) => r.json().title !== "",
    "is contains valid body": (r) => r.json().body !== "",
  });
}

Resources

I hope this article helps you to learn about API performance testing using k6.

Do you have any experience working on performance testing using k6? Please let me know in the comments down below

Thank you

How to serialize JSON API requests using Java Records?

Sun, 10 Nov 2024 05:01:58 +0000

JSON is a popularly used file format in the APIs as it is lightweight and self-describing.
JSON stands for JavaScript Object Notation and. It was derived from JavaScript and originally specified by Douglas Crockford.

JSON is easy to read, write, and language-independent, supporting data structures like arrays and objects for flexible organization. It is widely used by software teams and is a common choice for storing and transferring data. The RESTful APIs generally rely on JSON files to exchange data over HTTP.

In this tutorial blog we will learn to serialize the JSON API requests using Java Records.

What are Java Records?

A Java record is a special type of class designed specifically for working with immutable data. Java Records were introduced in Java 14 version as a preview feature and became a standard feature in Java 16.

Records offer a concise syntax for defining classes primarily intended to store immutable data.

The following is a simple example of Java Records:

public record Country(String name, long population) {
}

What is JSON Serialization?

JSON serialization is the process of transforming an object, data structure, or complex data type into a JSON (JavaScript Object Notation) format. For example, converting Java POJO into a JSON format.

During JSON serialization, each attribute of an object is converted into a JSON property, while nested structures (such as lists or other objects) are represented as JSON arrays or nested JSON objects. This helps in making the data more portable and accessible to other systems, programming languages, or APIs.

For example consider the following “Country” object using Java Records:

public record Country(String name, long population) {
}

With JSON serialization, an instance of the “Country” Record could be converted to JSON as shown below:

{
"name" : "India",
     "population":  "1.43 billion"
}

How to serialize JSON API Requests using Java Records?

API requests using request body in the JSON format can be serialized using Java Records easily through the Jackson Databind or Google Gson library. Java Records are convenient, lightweight and efficient as they automatically generate getters, as well as equals(), hashCode(), and toString() methods.

In this tutorial, we will be using the Rest-Assured library for executing the API requests and Jackson Databind library with Java Records for serializing the request body used in the API requests.

API under Test

We will be using the restful-ecommerce APIs in this blog for demonstration. It is free to use E-Commerce Web APIs for practicing API testing and is available over GitHub.

We will be using the docker-compose file to start the restful-ecommerce application and accordingly execute the API requests on our local machine.

Test Scenario

We will use the “/addOrder” API that will allow adding new orders in the system. The following is the request payload for the “/addOrder” API:

[ { 
    "user_id": "1",
    "product_id": "1",
    "product_name": "iPhone",
    "product_amount": 500.00,
    "qty": 1,
    "tax_amt": 5.99,
    "total_amt": 505.99
}]

The request accepts a JSON array with multiple JSON objects that holds the different order details.

We will serialize the JSON given in the payload using Java Records and execute the POST request to add order in the system verifying that the order is added successfully.

Configuration

We would be using the Maven project and adding the following dependencies in the pom.xml file.

<dependency>
   <groupId>org.testng</groupId>
   <artifactId>testng</artifactId>
   <version>7.10.2</version>
 </dependency>

 <dependency>
   <groupId>io.rest-assured</groupId>
   <artifactId>rest-assured</artifactId>
   <version>5.5.0</version>
   <scope>test</scope>
 </dependency>

 <dependency>
   <groupId>com.fasterxml.jackson.core</groupId>
   <artifactId>jackson-databind</artifactId>
   <version>2.18.1</version>
 </dependency>
 <dependency>

The dependencies are for TestNG that acts as a test runner, rest-assured for executing the API requests and Jackson Databind that will help in serialization.

Let’s create a new package - restful-ecommerce under the src/test folder in the project.

Let’s add two more packages under the restful-ecommerce page, the first one with name - pojo and the second one with name tests.

Test Implementation

The first step in implementation is to create Java Records with the fields needed for adding the Order as per the request payload.

The request payload requires the following fields, hence we will accordingly add those fields to the Record

user_id
product_id
product_name
product_amt
qty
tax_amt
total_amt

The data_type details for these fields can be found on the Swagger using which the fields in the Java Record can be created.

So, let’s add a new Java Record - “Order”, under the pojo package.

public record Order(String user_id, String product_id, String product_name, int product_amount, int qty, int tax_amt,
                   int total_amt) {
}

After adding the Java Record, we can straightaway move to write the API tests and create a new Java class - “AddOrderTests” under the tests package.

public class AddOrderTests {

@Test
public void testAddOrder () {

   List<Order> orders = new ArrayList<> ();
   orders.add (new Order ("1", "34", "Canon Camera CX12", 14500, 1, 915, 15415));

   given ().body (orders)
       .when ()
       .log ()
       .all ()
       .contentType (ContentType.JSON)
       .post ("http://localhost:3004/addOrder")
       .then ()
       .log ()
       .all ()
       .statusCode (201);

}
}

Code Walkthrough

The @Test annotation is from the TestNG library that will allow us to run the tests. The request payload actually accepts JSON Arrays in which multiple objects of Orders are added.

List<Order> orders = new ArrayList<> ();

The first statement in the method is creating a new list that can store Order objects. This will help us in adding multiple order objects to the list and accordingly pass them as the request body. This is done to ensure that we pass the JSON Object under JSON Arrays as the "/addOrder" endpoint needs the request body in JSON Array format.

orders.add (new Order ("1", "34", "Canon Camera CX12", 14500, 1, 915, 15415));

The second line in the method adds an object of Order with details. See how simple it is to pass the value to the Records object, Records automatically generates the required constructor for passing the values.

Next, using rest-assured methods the test for the API is written.

given ().body (orders)
   .when ()
   .log ()
   .all ()
   .contentType (ContentType.JSON)
   .post ("http://localhost:3004/addOrder")
   .then ()
   .log ()
   .all ()
   .statusCode (201);

The interpretation of the above code is pretty simple: given a body of order objects, log the request details in the console, the content-type of the request body will be in JSON format.

The Post HTTP method should be hit for the API endpoint “http://localhost:3004/addOrder”, when the API is executed, then the response details received should be logged in the console and its status code should be checked that should be equal to 201.

Test Execution

Before we execute the test, we should make sure that the restful-ecommerce application is up and running. We can start the application using the following docker compose command:

docker compose -f docker-files/docker-compose-ecommerce.yml up -d

We can then hit the following URL to make sure that the application is up and running. It should display the Swagger docs

http://localhost:3004/api-docs/

Next, we can run the test and check for the output. The following screenshots show that the JSON is serialized successfully in the API request body.

The addOrder API is successfully hit and one order is generated.

Summary

Java Records introduced in Java 16 are convenient, lightweight and efficient as they automatically generate getters, as well as equals(), hashCode(), and toString() methods.

It can be a better fit for JSON serialization and deserialization with Jackson Databind library as it does not require writing a lot of boilerplate code.

All the code examples shown in this article can be found over on GitHub.

Happy Testing!