DEV Community: Liudas

Automation Before Automation (ABA) — A Missing Phase in Modern Testing?

Liudas — Tue, 16 Jun 2026 05:13:19 +0000

Software testing is usually described in two large categories: exploratory testing and automated testing. Exploratory testing is about investigation and discovery. Automated testing is about repeatable verification and regression protection. Both are well established, well documented, and widely practiced.

In real projects, however, the workflow is rarely that clean.

After implementing a new endpoint or modifying existing functionality, teams do not immediately start by building a long-term automated regression suite. First, they try to understand how the system actually behaves. They vary inputs, test boundary conditions, send invalid data, alter payload structures, observe status codes, and look for unstable behavior. Increasingly, this is not done purely manually. Teams use fuzzers, mutation tools, schema-driven generators, and AI-assisted test generation to execute hundreds of variations in minutes.

The purpose of this activity is not regression protection. The generated tests are often temporary and disposable. Their value lies in the information they reveal quickly: weak validation, inconsistent error handling, unexpected 500 responses, protocol inconsistencies, or fragile assumptions in the backend.

Despite being common, this phase has no widely accepted name. It is often grouped under exploratory testing, even though it involves automated generation and execution. It is also sometimes confused with traditional test automation, even though it does not produce long-term maintainable suites integrated into CI/CD.

This intermediate layer deserves clearer definition.

In a recent white paper, I propose the term Automation Before Automation (ABA) to describe this activity. ABA refers to the practice of automatically generating and executing exploratory, validation, robustness, and protocol-level tests before creating and maintaining traditional automated test suites. In short, it is automated exploration before automated verification.

The distinction matters because the goals are different. Traditional automated testing answers the question: how do we ensure this does not break again? ABA answers a different question: what do we not yet understand about this implementation?

Automation focuses on protecting known expectations. ABA focuses on exposing unknown behavior. Automation produces confidence over time. ABA produces information quickly.

With the rise of fuzzing technologies, property-based testing, AI-assisted generation, and automated protocol exploration tools, this intermediate phase is becoming more visible in practice. Yet without a shared vocabulary, it is often undervalued or performed informally. In some cases, teams automate too early, locking in happy-path assumptions before seriously challenging how the system behaves under imperfect input.

The white paper does not introduce a new testing technique. It attempts to formalize and characterize a testing activity that many teams already perform but rarely define explicitly. By naming and structuring it, we can reason more clearly about when it should happen, what tools belong to it, and how it complements rather than replaces traditional automation.

If this resonates with how your team works in practice, you may find the full paper useful.

Automation Before Automation (ABA): An Intermediate Phase in Modern Software Testing - https://qaontime.com/research/automation-before-automation.html

Zenodo DOI: https://doi.org/10.5281/zenodo.20720442

I am particularly interested in perspectives from teams using fuzzing, property-based testing, schema-driven generators, or AI-assisted test generation in early development stages. Is this truly a distinct phase, or simply a reframing of existing practices?

Is the QA profession really disappearing?

Liudas — Fri, 12 Jun 2026 12:43:03 +0000

The first time I heard that testers would soon become unnecessary was around 2008, when Selenium RC started gaining popularity. The narrative back then was simple: everything will be automated. We will only need people who can write automation. Manual testing would disappear.Eighteen years later, QA is still here.

Today the conversation has shifted. With the AI boom, the focus is no longer on testers — it is on developers. We are told that programmers will soon be unnecessary because AI can write code. Everyone can now generate software. Within two or three years, most engineering jobs will disappear. After that, humanoid robots will replace the rest.
If that were true, QA would logically disappear even faster. If AI writes the code, surely it can test it too.

So I asked LinkedIn a simple question: When will AI replace most QA Engineers?

More than 3,000 people saw the poll. 233 voted. The results were interesting: 68% chose “Never.” Seven percent said within 10 years. Five percent said within 5 years. Ten percent said within 2 years. Three percent believed most QA would be replaced by 2026. I intentionally did not define what “Never” means. Predicting what happens in 1,000 years is pointless. I interpret “Never” as within our professional lifetime — the next 50 to 70 years.

Now let’s get to the core question.

Is it theoretically possible for AI to test a product completely autonomously? Let’s imagine we reach superintelligence, and it decides not to eliminate us. It builds products, writes code, and executes tests. Do we still need human testers?

If we build products for humans, then humans must ultimately evaluate their quality. It really is that simple.

AI can accelerate testing. It can generate test cases, simulate edge conditions, analyze logs, and improve coverage. It can automate enormous parts of the process. But quality is not only about assertions and passing checks. Quality is about usability, clarity, expectations, frustration, trust, and real-world experience.

If a system is built for another system, AI can evaluate AI. But if a product is built for people, human judgment remains essential.

And this leads to a bigger issue.

For the past four years, we have been told that AI will replace 95% of jobs within two or three years. This prediction has been repeated constantly since 2022. Every year, the same timeline: two or three more years. But four years have already passed.

If such a massive replacement was truly imminent, we would already see undeniable structural changes: entire professions collapsing, universities shutting down programs, mass technological unemployment driven directly by AI-native systems. Instead, what we mostly see is optimization.

Developers still develop — just faster. Designers still design — with generative assistance. Content creators still create — with AI drafts. Students still search for information — now through chat interfaces instead of Google.

The behavior model remains the same. The workflow is accelerated. That is optimization, not transformation.

When PayPal appeared, it changed how we send money. Gmail changed expectations about storage overnight. Facebook changed social interaction. YouTube changed media consumption. Shopify changed online commerce. The iPhone reshaped the entire mobile ecosystem. Netflix transformed distribution. Airbnb changed travel. Uber changed transportation behavior so deeply that children today cannot imagine calling a taxi by phone. Instagram reshaped visual sharing. Ethereum created a new financial layer. TikTok reinvented content discovery. Each of these products changed how people behave at scale.

Now it is 2026. ChatGPT launched in 2022 and triggered the modern AI wave. So here is the honest question: What product have we created with AI help in the last four years that has fundamentally changed human behavior at that level? None.

AI is clearly powerful. It is a horizontal layer across industries. It accelerates, enhances, and automates. But has it produced a new behavioral infrastructure comparable to the smartphone, ride-sharing, or algorithmic short-form media? So far, what we mostly see are optimizations built on top of existing models.

This does not mean AI is insignificant. It is extremely important. But there is a difference between a productivity multiplier and a civilization-level behavioral shift.

QA is not disappearing. The same applies to development. The stronger claim — that most jobs will vanish within two or three years — has been repeated for four years without materializing.

Maybe a true AI-native behavioral revolution is still ahead of us. But if the timeline is always “two or three years away,” then perhaps the prediction deserves more scrutiny than applause.

Daugiau apie testuotojo specialybę rašau savo knygoje https://itknyga.lt lietuvių kalba.

API testing has no shortage of great tools

Liudas — Tue, 09 Jun 2026 06:21:38 +0000

Postman made API development mainstream.
Schemathesis pushed specification-based testing forward.
ReadyAPI is packed with enterprise features.
OWASP ZAP and Burp Suite are essential for security testing.
Tusk Drift takes a completely different traffic-driven approach.

The problem is that they solve different problems.

We kept running into a simple situation:

“I have one API request. I don’t have a specification. I don’t have production traffic. I don’t want to spend hours configuring tools. I just want a quick reality check.”

That’s the gap Rentgen was built for.

Not to replace existing tools. Not to compete with everything. Just to make it ridiculously easy to find issues early, when all you have is a single request and a few seconds.

Sometimes the hardest part isn’t writing tests.

It’s figuring out what should be tested in the first place. 🎯

Automation before automation: Rentgen.io

The ChatGPT That Appeared in 2005 Destroyed the Programming Industry — But You Didn’t Notice

Liudas — Wed, 20 May 2026 06:03:23 +0000

This is how Facebook was introduced in 2004 — or sometime around then.

Look at the design. Look at the UX decisions. Or better yet, look at the technical choices. The front end was built with HTML, CSS, and JavaScript; the back end ran on PHP; the database was MySQL; everything was served on an Apache server — and all of it was built in just one or two weeks of work.

Today it looks primitive. But at the time, it was modern. It was cutting edge. It was a product that changed the world.

Around the same years, Amazon’s user interface was significantly redesigned, simplifying navigation down to a few essential choices, and it looked roughly like this:

Nothing impressive by today’s standards, but at the time it was a massive system with complex infrastructure, supported by thousands of servers and millions of users.

And it was a revolution in the world of email. The storage offered: 1000MB. At the time, Hotmail or Yahoo offered 2–6MB. The difference was not in percentages, but in multiples. JavaScript + AJAX solutions made it possible not to refresh the page every time you opened an email, and it felt like the future, like something that would rewrite the rules.

Also around 2004, eBay was already an infrastructure giant with a product like this:

Millions of auctions, real-time bidding, a global audience, PayPal as the most advanced payment solution — and it was the highest-quality technology available on the market.

All of these products were modern and technologically cutting-edge at the time. I used them myself, and I didn’t have even the slightest doubt that this was the pinnacle of quality, engineering excellence, and ingenuity.

Now let’s imagine a fiction.

At the end of 2005, ChatGPT appears. It is trained on all these cutting-edge systems — Facebook, Amazon, Gmail, eBay. It sees PHP, MySQL, Apache, Oracle, C++, AJAX. It sees the best architectural solutions that existed at the time. It sees what is the technological peak of the world.

And the same thing begins that is happening today.

Everyone explains that programmers will no longer be needed. That creating a new eBay is a matter of minutes. That it’s enough to write a prompt and the system will generate the entire application. Everyone builds applications, everyone generates code, everyone combines what already exists. Everything looks advanced. Everything looks like it’s changing the rules of the game.

But what does that 2005 ChatGPT actually create?

It optimizes PHP. It generates better MySQL query templates. It makes nicer HTML. It combines AJAX with what already exists. It creates combinations from what it sees around it. It does not cross the boundaries of its era, because those boundaries do not yet exist in its training data.

And then, somewhere in parallel, people begin working on Go and present it publicly in 2009. A language that changes thinking and simplicity in infrastructure code. In 2009, Node.js and npm appear, changing the server-side JavaScript model. In 2009, MongoDB appears, questioning the dominance of relational databases. In 2013, Kubernetes appears, fundamentally changing how we manage containers and distributed systems. In 2015 — React Native, and so on, and so forth.

Now let’s think critically.

In 2005, with ChatGPT available, would Kubernetes have appeared? Would the Go language have appeared? Would a document-oriented NoSQL database have appeared if the model had been trained only on the dominance of relational systems? Would a new asynchronous server model have appeared if the standard at the time had been completely different?

The answer is very simple. AI would not have created it. A human would.

Because it does not yet exist in its training data. It cannot generate what the world has not yet invented. It can combine, optimize, accelerate — but it cannot create an architectural breakthrough out of nothing if there are no precedents for that breakthrough.

Yes, it is a fact that with AI some technologies would have appeared faster. But they would not have appeared because AI invented them. They would have appeared because humans questioned what at the time seemed self-evident.

And now let’s look at today. Everything that today seems modern, advanced, intelligent, and inevitable will, in 20 years, look just as simple and even slightly amusing as the 2004 eBay homepage looks today — even though it was the flagship of technology. And perhaps in 20 years someone will say: “Can you imagine, they seriously believed that prompts could replace all of engineering.”

Technologies change. Tools change. AI will also change. But architectural breakthroughs are still created by people who begin to think differently than the data of their time allows. And here the question is not whether AI will replace programmers. The question is who will create the next Kubernetes.

chatGPT of 2005 - https://itknyga.lt/2005-chatgpt/

API reality checks from your terminal

Liudas — Fri, 15 May 2026 09:16:12 +0000

Soon

Export a .rentgen project once, then run Rentgen from the terminal, Docker or CI/CD pipelines. No cloud runner. No hosted sync. No extra scripting layer. Just the same local-first checks that expose fragile API behavior before automation becomes expensive.

Thunder Client vs Rentgen — one checks if the API works, the other checks how it breaks

Liudas — Thu, 14 May 2026 17:22:21 +0000

Modern API development has become slightly absurd. A developer sends one request from inside VS Code, gets a beautiful green 200 OK, leans back in the chair like a Formula 1 engineer after a flawless pit stop, and declares: “Yep. Works.”

Except… no. It doesn’t. It means one request worked once.

And this is exactly where Thunder Client and Rentgen stop being competitors and start becoming two completely different tools living in different parts of the API lifecycle.

Thunder Client is excellent at what it was built for. It keeps API requests inside the editor, close to the code, without forcing developers to open another giant platform with seventeen tabs, sync popups, team workspaces, cloud agents, and whatever else modern software companies now consider “essential productivity”.

You change an endpoint. You send a request. You inspect the response. You tweak headers. You debug quickly. Perfectly reasonable workflow.

But then reality arrives.

Because production systems are not attacked by perfectly formatted JSON created by calm developers drinking oat milk lattes at 2 PM. Production gets malformed payloads, oversized bodies, missing fields, broken enums, invalid types, whitespace disasters, incorrect casing, expired tokens, and integrations written by someone who clearly hates humanity.

And that is the gap Rentgen was built for.

Rentgen takes the request that already “works” and immediately starts behaving like the worst possible API consumer imaginable. Missing required fields? Good. Wrong data types? Excellent. Malformed JSON? Fantastic. Status code inconsistencies? Even better.

Not because chaos is fun, but because these are the exact bugs teams somehow keep discovering in production after proudly announcing the endpoint was “tested”.

Thunder Client helps you build and debug APIs. Rentgen helps you discover whether the API behaves like an adult once the input becomes messy.

Different jobs. Different pressure. Different moment in the workflow.

One is an API client.

The other is an API hygiene scanner.

And pretending they compete directly makes about as much sense as comparing a torque wrench to an X-ray machine.

Full original article:
https://rentgen.io/api-stories/Thunder-Client-and-Rentgen-testing-inside-editor-reality-checking-outside-happy-path.html

ReadyAPI vs Rentgen: One Builds Enterprise Confidence. The Other Checks If the API Falls Apart Before That.

Liudas — Wed, 06 May 2026 18:51:14 +0000

There’s a funny moment in API development that almost nobody talks about.

A developer finishes an endpoint, sends one request, gets a beautiful 200 OK back, and suddenly the room behaves like the API survived Normandy.

Then somebody opens ReadyAPI, starts building proper test suites, adds assertions, environments, CI integration, performance checks, maybe even security testing. Serious enterprise stuff. And to be fair, ReadyAPI absolutely deserves its reputation. SoapUI evolved into one of the biggest API testing platforms for a reason. Banks, telecoms, healthcare systems — this is the territory where structured testing matters and auditors enjoy PowerPoint presentations about “quality gates”.

But there’s a problem hiding before all of that.

What if the endpoint was already fragile before the first test suite even existed?

That’s the gap Rentgen focuses on.

Not enterprise automation. Not giant regression packs. Just the uncomfortable two-minute reality check right after “it works”.

Take one working cURL request and start making it slightly annoying. Remove fields. Break types. Add whitespace. Push boundaries. Send malformed payloads. Suddenly APIs that looked very confident five minutes ago begin returning strange status codes, inconsistent validation, or the occasional glorious 500 error.

And honestly, that’s useful.

Because building beautiful automation around assumptions is still building automation around assumptions.

ReadyAPI helps teams define and enforce correctness over time. Rentgen helps expose weird backend behavior before those definitions even exist. Different stage. Different responsibility. No reason they can’t work together.

Full article:
https://rentgen.io/api-stories/ReadyAPI-and-Rentgen-enterprise-test-suites-and-step-before-them.html

Thunder Client vs Rentgen is one of those comparisons that sounds logical until you actually look at how people use them.

Liudas — Tue, 05 May 2026 16:56:35 +0000

Both deal with API requests, both sit somewhere in the development flow, and both are useful. But putting them in the same box is a bit like comparing a screwdriver with a crash test. Yes, both are involved in building things. No, they are not doing the same job.

Thunder Client lives exactly where developers spend most of their time — inside the editor. You write some code, tweak an endpoint, open Thunder Client, send a request, get a response, fix something, repeat. It is fast, lightweight, and does not force you to jump between tools like a caffeinated squirrel. For day-to-day development, that convenience matters more than people like to admit.

But here is the part everyone quietly skips. You send a request, it returns 200, JSON looks fine, and someone inevitably says “works.” Which is technically correct, in the same way that starting a car proves it can move forward. It does not prove the brakes work when you actually need them.

Manual API clients, including Thunder Client, do exactly what you tell them to do. Nothing more, nothing less. If you test a valid request, you get a valid response. If you think about edge cases, you can test them too. But that thinking still depends on you. And when deadlines are tight, nobody is sitting there inventing fifty creative ways to break their own endpoint just for fun.

That is where the story changes. Instead of asking “does this request work,” the more interesting question is “what happens when this request stops being polite.” Missing fields, wrong types, oversized payloads, malformed JSON, broken tokens, weird casing, extra data nobody asked for. The kind of input that always shows up in production, usually at the worst possible moment.

That is the gap Rentgen is built for. Not to replace the editor workflow, not to compete with API clients, but to take one working request and push it a bit harder. You copy the cURL, drop it in, and instead of manually crafting edge cases, you get a whole set of variations automatically. Some APIs handle it well. Some respond like they have just seen a ghost. Both outcomes are useful.

The difference is not about features or UI. It is about responsibility. Thunder Client helps you build and verify your API while you are working. Rentgen helps you challenge the assumptions behind that work before you move on. One keeps things smooth. The other makes things slightly uncomfortable. And if you have spent enough time debugging production issues, you already know which one tends to reveal the interesting problems.

The workflow is actually simple when you stop trying to compare them. Use Thunder Client while building. Keep everything close to your code, move fast, get feedback, fix things. Once the request works, take that same request and run it through Rentgen. Now you are no longer testing what you expected. You are testing what you forgot.

That shift matters more than most teams realize. Because a lot of automation is built on top of assumptions that were never properly challenged. You end up with clean test suites that quietly ignore the messy cases. And those messy cases are exactly where bugs like to hide.

So no, this is not Thunder Client vs Rentgen in the usual sense. One is an API client. The other is a reality check. One helps you build. The other helps you find out what you missed before someone else does.

Full article: https://rentgen.io/api-stories/Thunder-Client-and-Rentgen-testing-inside-editor-reality-checking-outside-happy-path.html

Without cURL, Rentgen Doesn’t Exist — But cURL Alone Isn’t Enough

Liudas — Mon, 04 May 2026 14:48:16 +0000

I’ve seen this pattern too many times to ignore. You write a clean cURL request, hit enter, get a nice 200 back, JSON looks good, and suddenly everyone relaxes like the job is done. cURL is brilliant at that moment. It is simple, direct, brutally honest. You send exactly what you wrote and the server responds. No magic, no abstraction, just raw truth. And that’s exactly why developers trust it. If something works in cURL, you know what was sent. But here’s the uncomfortable part: it only proves that one exact request worked once. Nothing more.

Real APIs don’t live in that perfect scenario. Fields go missing, values change, types break, tokens expire, payloads get messy, and clients behave in ways nobody planned for. And suddenly that clean request doesn’t mean much anymore. You could write dozens of variations by hand in cURL, but let’s be honest, nobody wants to sit there crafting broken payloads all day just to see if something explodes.

This is where I ended up building something on top of that idea. Instead of replacing cURL, just extend it. Take one working request and start asking a better question: what happens when this request stops being perfect? That’s the gap. That moment between “it works” and “it actually survives real input.” Turns out that’s where most of the interesting problems live. Inconsistent validation, weird status codes, backend 500s that should never exist, responses that make debugging unnecessarily painful.

The workflow is simple and it makes more sense than pretending one tool can do everything. Use cURL to get the request right. Then take that exact request and push it a bit. Remove fields, break types, stretch boundaries, mess with payloads. Now you’re not testing one scenario anymore, you’re seeing how the API behaves in reality. And that’s a very different picture.

A lot of teams jump straight from a working request into automation. They build clean test suites around clean scenarios and feel safe. But automation built on assumptions is just a faster way to miss things. If you don’t explore the messy cases first, your tests will simply never cover them.

So no, this is not cURL vs anything. cURL stays exactly where it belongs — as the ground truth. But one request proving it works is only half the story. The other half is figuring out what breaks. And that’s where things actually get interesting.

Full version: https://rentgen.io/api-stories/cURL-and-Rentgen-one-proves-it-works-the-other-proves-what-breaks.html

HTTPie vs Rentgen is one of those comparisons that sounds sensible right up until the moment you realise they’re not even playing the same sport.

Liudas — Sun, 03 May 2026 06:41:38 +0000

Yes, both talk to APIs, but so does half the internet, and we don’t compare a terminal tool with a stress test for the same reason we don’t compare a steering wheel with a crash test. HTTPie is there to make requests readable, clean, almost pleasant. You type something that looks like English instead of a cursed cURL command, hit enter, and the API politely responds. It’s fast, it’s human, and it’s exactly what you want when you’re building or debugging something without losing your will to live.

And then, of course, comes the dangerous bit. The request works. The response looks fine. Everyone leans back and says, “good enough.” This is where reality quietly clears its throat. Because that one perfect request doesn’t prove your API is solid, it proves that one carefully constructed scenario didn’t fall apart. Everything else is still a mystery. Missing fields, wrong data types, strange payloads, expired tokens, random whitespace, and all the other things real systems throw at your backend are still waiting their turn.

HTTPie doesn’t pretend to solve that, and it shouldn’t. It does its job properly. It lets you talk to the API like a normal human being instead of fighting with syntax. But it will only ever send what you ask it to send. If you don’t think about edge cases, they don’t exist. If you don’t test something, it remains untested. Simple, honest, slightly terrifying.

This is where Rentgen wanders in, not as a replacement, but as the slightly annoying colleague who asks uncomfortable questions. You take that same working request, drop it in, and suddenly the API is dealing with all the things you didn’t bother to try. Fields disappear, values change, payloads get ugly, and the system is forced to respond to something closer to reality. Sometimes it handles it gracefully. Sometimes it produces errors that make you wonder how this ever reached production. Nothing dramatic, just the usual collection of “we probably should have tested that.”

The difference isn’t power, it’s timing. HTTPie lives in the moment where you build and understand the request. Rentgen lives right after, when you ask whether that understanding was actually complete. One gives you clarity, the other gives you doubt, and you need both if you don’t enjoy debugging things at three in the morning.

Used properly, they fit together perfectly. You build the request with HTTPie, make sure it works, then you let Rentgen make it slightly uncomfortable. Fix what breaks, learn what matters, and only then turn that knowledge into proper tests. That way you’re not automating guesses, you’re automating reality.

HTTPie helps you speak to your API. Rentgen helps you find out what your API says when things stop being polite. Same request, different purpose, no drama required.

Full version here: https://rentgen.io/api-stories/HTTPie-and-Rentgen-first-talk-to-the-API-then-make-it-uncomfortable.html

Insomnia vs Rentgen — powerful API platform vs raw API reality

Liudas — Fri, 01 May 2026 18:41:38 +0000

Insomnia vs Rentgen is one of those comparisons that sounds logical until you actually think about it for more than five seconds. Yes, both deal with APIs, but so does electricity and your toaster, and nobody is comparing those. Insomnia is a proper API platform. You build requests, manage collections, write assertions, run tests, sync with Git, collaborate with teams and generally behave like a responsible adult. It’s structured, repeatable, and absolutely necessary once your API stops being a toy and starts becoming a system.

Rentgen doesn’t even try to compete with that. It shows up earlier, at that suspiciously quiet moment when the first request returns 200 and everyone suddenly decides the job is done. That’s where things usually go wrong. Because one clean request doesn’t prove the API works, it proves that one carefully crafted scenario didn’t explode.

Insomnia works with what you define. If you don’t test missing fields, they don’t exist. If you don’t try invalid data types, wrong casing, broken payloads or boundary values, the system will happily pretend those problems don’t exist… right until production proves otherwise. And production is very good at proving people wrong.

Rentgen flips that around. Instead of asking you to think of every edge case, it assumes you didn’t. You take one real cURL request, drop it in, and suddenly the API is dealing with missing fields, garbage input, weird payloads, and all the things real systems eventually send whether you like it or not. No ceremony, no scripts, just a fast way to see how fragile the endpoint actually is.

The real difference is timing. Insomnia lives in the main workflow. It’s where you build, test, debug, and maintain your API over time. Rentgen lives before that. It’s the uncomfortable reality check before you start writing beautiful automation around assumptions that were never challenged.

And that matters, because a lot of teams go straight from “it works” to “let’s automate it” and end up with test suites that look impressive but quietly ignore half the problem space. Automation based on assumptions is just a very efficient way to be wrong.

Used properly, they sit next to each other perfectly. Build and understand the request in Insomnia, then take that exact request, run it through Rentgen, fix what breaks, and only then turn it into proper tests. That way you’re automating reality, not wishful thinking.

Insomnia helps you build and manage API systems. Rentgen helps you find out what those systems don’t handle yet. Same request, different phase, completely different job.

Full breakdown here: https://rentgen.io/api-stories/Insomnia-vs-Rentgen-powerful-API-platform-vs-raw-API-reality.html

Hoppscotch vs Rentgen? Not really. One sends requests. The other breaks them.

Liudas — Thu, 30 Apr 2026 15:19:34 +0000

There’s a funny moment in every API project.

You send a request.

It returns 200.

JSON looks clean.

Everyone nods.

“Works.”

And that’s exactly where things usually start going wrong.

The clean illusion

Tools like Hoppscotch are brilliant at what they do.

Fast. Lightweight. Open-source.

You send requests, tweak headers, manage collections, debug responses — all the good stuff.

It’s the modern version of “does the API respond?”

And that matters.

Because without a tool like that, you’re basically copying cURL commands between tabs like it’s 2008.

But here’s the uncomfortable part

That one successful request?

It proves exactly one thing:

👉 That exact request worked once.

That’s it.

It says nothing about:

missing fields
wrong data types
extra whitespace
invalid enums
malformed payloads
broken auth
or the classic: “why is this returning 500?”

And that’s not a tooling problem.

That’s just how manual testing works.

Where Rentgen shows up

Rentgen starts right after that “it works” moment.

Not to replace Hoppscotch.

To question it.

You take the same request.

Paste it in.

And suddenly you’re not testing one scenario anymore.

You’re testing dozens.

Fields disappear.

Types change.

Payloads break.

Headers go weird.

And now the API has to deal with reality.

This is where things get interesting

Because APIs behave very differently when input stops being polite.

Some handle it well. Clean 4xx responses, consistent validation.

Others… panic.

500 errors where there shouldn’t be any
inconsistent status codes
HTML responses from JSON APIs (yes, still happens)
validation that works sometimes and then just… gives up

Nothing exotic. Just the boring stuff nobody tests properly.

The real difference

Hoppscotch gives you control.

Rentgen gives you pressure.

One helps you ask a question.

The other slightly messes up the question and watches what happens.

A workflow that actually makes sense

Use Hoppscotch (or any API client) to:

build the request
understand the endpoint
confirm the happy path

Then:

Take that exact request → run it through Rentgen.

Now you're asking a better question:

👉 What happens when this request stops being perfect?

Why this matters

A lot of teams go straight from “200 OK” to automation.

They build test suites around clean scenarios…

and accidentally automate assumptions.

That’s how you end up with beautiful CI pipelines

testing things that were never really explored.

The simple version

Hoppscotch → work with APIs
Rentgen → challenge APIs

Same request.

Different job.

If you want the full breakdown (without me trying to be clever), I wrote a detailed version here:

👉 https://rentgen.io/api-stories/Hoppscotch-vs-Rentgen-API-client-and-API-reality-check-are-not-the-same-job.html