DEV Community: Liudas

Tusk Drift vs Rentgen: Traffic Replay vs Early API Discovery

Liudas — Tue, 04 Aug 2026 06:00:59 +0000

API quality is improving rapidly, but different tools solve different problems.

Recently I looked at Tusk Drift, and I think it introduces an interesting idea: recording real production traffic and replaying it as regression tests. At first glance it may seem similar to Rentgen, but after looking closer, the two tools actually sit at different stages of the API lifecycle.

They complement each other rather than compete.
Tusk Drift starts with production traffic
Tusk Drift records real API requests generated by users or integrations and later replays them as regression tests.
The goal is straightforward: Did today’s code change break behavior that already existed yesterday?
This is extremely valuable because production traffic often exercises scenarios nobody thought to automate manually. Instead of maintaining hundreds of regression tests yourself, you can reuse what users are already doing.
For mature systems, that’s a powerful safety net.

Rentgen starts with a single request

Rentgen works much earlier.
It doesn’t need production traffic.
It doesn’t need historical traces.
It doesn’t even need an existing test suite.
It starts from one working cURL request (or a request imported from Postman, Swagger, logs, or another client).
From there Rentgen automatically generates hundreds of API checks by mutating that request:

missing fields
invalid data types
boundary values
oversized payloads
malformed JSON
unsupported HTTP methods
invalid enums
whitespace problems
authentication scenarios
protocol validation The question Rentgen asks is completely different: How does this endpoint behave when the input stops being clean?

Different questions

Tusk Drift asks: Has behavior changed?
Rentgen asks: Is behavior robust?
Those are not the same thing.
An API can replay production traffic perfectly while still crashing on unexpected input.
Likewise, an API may survive every malformed request Rentgen generates but still introduce regressions after future code changes.
Both are important.

Different timing

This is probably the biggest distinction.
Tusk Drift
Works best when:
the service already has users
production traffic exists
behavior is worth protecting
Rentgen
Works even if:
the endpoint was created five minutes ago
there are no users
there is no production traffic
there is no regression suite
One working request is enough.

A practical workflow

These tools actually fit together quite naturally.
Build a new endpoint.
Run Rentgen locally from a single cURL request.
Fix validation gaps, unexpected 500 errors, inconsistent responses, and weak input handling.
Deploy.
Let users generate real traffic.
Use Tusk Drift to replay that traffic as regression tests.
One discovers problems before release.
The other makes sure they never silently return.

No replacement story

I don’t see these tools replacing each other.
Tusk Drift is not trying to be an API mutation engine.
Rentgen is not trying to record and replay production traffic.
They’re solving different problems at different moments in the software lifecycle.
That’s why comparing them is interesting. Not because one wins. Because together they cover more of the API quality journey.

The complete comparison, including diagrams and examples, is available here: https://rentgen.io/api-stories/Tusk-Drift-and-Rentgen-replaying-real-traffic-vs-breaking-one-request-early.html

Apigee and Rentgen: API Management Is Not API Testing

Liudas — Wed, 29 Jul 2026 17:41:25 +0000

If you work with APIs, you've probably heard of Apigee. You may also have come across Rentgen. Since both tools operate in the API space, it's easy to assume they solve similar problems. They don't.

They work at different layers of the API lifecycle.

Apigee manages APIs. Apigee is an API management platform. It helps organisations expose, secure, monitor and govern APIs at scale.

Typical responsibilities include:

API Gateway
Authentication & Authorization
Rate limiting
Traffic management
Policies
Analytics
Developer portal
API product management

When your APIs become products consumed by customers, partners or internal teams, this layer becomes essential.

Rentgen tests API behaviour. Rentgen starts with a single working cURL request. Instead of managing traffic, it asks a different question: How does this endpoint behave when the input is no longer perfect?

It automatically generates request variations such as:

Missing required fields
Invalid data types
Boundary values
Empty strings
Malformed JSON
Unsupported HTTP methods
Invalid headers

The goal isn't automation. The goal is understanding endpoint behaviour before automation begins. Different layers.

One of the biggest misconceptions is believing that an API gateway somehow guarantees API quality. It doesn't.

A gateway can enforce authentication, quotas and routing, while the backend may still:

return unexpected 500 errors
accept invalid values
expose inconsistent validation
produce confusing error responses

These are implementation problems, not infrastructure problems. That's where endpoint-level testing becomes valuable.

Rather than choosing one tool over the other, they fit naturally into different stages of API development.

Build the endpoint.
Test its behaviour with Rentgen.
Fix validation and reliability issues.
Publish and manage the API with Apigee.

One focuses on implementation quality. The other focuses on operating APIs at scale. Both are important.

If you'd like the full comparison with more examples and discussion, you can read the original article here: https://rentgen.io/api-stories/Apigee-and-Rentgen-managing-API-traffic-is-not-same-as-testing-API-behavior.html

API testing starts too late

Liudas — Tue, 28 Jul 2026 04:01:29 +0000

A lot of API testing still begins the same way: send one valid request, get a 200 back, and move on. The problem is that a single successful response proves almost nothing about how the API behaves when its assumptions are disturbed.

It does not tell you what happens with malformed input, boundary values, missing authentication, oversized payloads, unsupported methods, or inconsistent protocol behavior. And by the time these things are checked properly, teams are often already deep into writing and maintaining full automation suites.

That gap is what I call Automation Before Automation (ABA): an early discovery phase that happens after a request first works, but before a maintainable regression model exists.

For APIs, this means taking one known-good request and systematically challenging it:

invalid values
boundary conditions
missing fields
malformed structures
protocol edge cases
security hygiene checks
early performance signals

The goal is not to replace proper automation. The goal is to generate broad, reviewable evidence quickly enough to show how the API actually behaves before you invest in long-term tests.

That is the idea behind Rentgen: a deterministic, local-first API testing tool that expands one working request into structured mutations and protocol checks, then records what the system really does.

It is not meant to prove business correctness or replace domain-specific tests. It is meant to expose validation gaps, protocol inconsistencies, weak error handling, and other early signals that teams often discover too late.

If that idea resonates, I wrote a full white paper on it here:

RENTGEN: Behavior-First API Testing Before Automation

https://qaontime.com/research/rentgen-white-paper.html

REST-assured and Rentgen: Different Tools, Different Jobs

Liudas — Sun, 26 Jul 2026 13:16:06 +0000

People often compare REST-assured and Rentgen, but they solve different problems.

REST-assured is a Java library for building reliable API regression tests. You already know what the API should do, and you automate those expectations.

Rentgen starts earlier.

Give it one working cURL request and it explores how the API behaves with missing fields, invalid values, malformed payloads, authentication edge cases, unsupported methods, and more. The goal isn't to replace coded automation, but to discover what is actually worth automating.

A workflow that makes sense:

Build the endpoint.
Run it through Rentgen to understand its real behaviour.
Fix the obvious issues.
Capture the important scenarios with REST-assured.
Run everything in CI/CD.

Discovery first. Regression second.

Both tools belong in the same API testing workflow—they just solve different problems at different stages.

You can find the full story here: https://rentgen.io/api-stories/REST-assured-and-Rentgen-coded-API-tests-and-eality-check-before-them.html

Swagger and Rentgen: Different Tools for Different Questions

Liudas — Wed, 15 Jul 2026 03:52:16 +0000

People occasionally ask me whether Rentgen is trying to replace Swagger. The short answer is no.

In fact, I think Swagger is one of the best things that happened to API development. Without it, many modern APIs would be painful to build and even harder to consume. OpenAPI gives teams a common language. Developers know what they’re building, frontend developers know what to expect, and third parties know how to integrate with the API.

The problem starts when we assume that because the specification is correct, the implementation must also be correct. Those are two completely different things.

Swagger describes how the API should behave. The backend is still just code written by humans, and humans make mistakes. A required field might accidentally become optional. Validation might stop working after a refactoring. Invalid JSON might return a 500 instead of a 400. A payload that should be rejected might quietly pass through. None of that makes Swagger bad. It simply isn’t trying to solve that problem.

This is exactly why I built Rentgen. Rentgen doesn’t read your OpenAPI specification. It doesn’t try to understand your intentions. It starts with a real request, usually copied as cURL from Swagger UI, browser DevTools, Postman, or logs, and asks a different question: “What happens if this request isn’t perfect?”

Instead of sending only the happy path, it starts changing things. Fields disappear. Values become too long. Types become invalid. Payloads become malformed. Authentication changes. Headers disappear. Then it watches how the backend responds. Sometimes nothing interesting happens. Sometimes you discover that the API happily accepts data it shouldn’t. Sometimes you discover that one missing quote crashes an endpoint with a 500.

Those are not theoretical problems. They’re exactly the kind of bugs I kept finding while testing production systems.

Over the last twenty years, I’ve noticed something else. Most teams start automation surprisingly late in the process. They write Postman collections, Playwright tests, REST Assured suites, or CI pipelines before they’ve really explored how the API behaves outside the documented scenario.

That’s the idea behind Automation Before Automation (ABA). Before investing hours or days into automated tests, spend a few minutes understanding the real behaviour of the API. Find the obvious validation problems. Fix them. Then automate.

The automation you build afterwards is usually better because it’s based on reality instead of assumptions.

For me, Swagger and Rentgen fit naturally into the same workflow. Swagger helps me understand the contract. I copy a request from Swagger UI, paste it into Rentgen, and let it explore the implementation. Only after that do I start writing long-term automated tests.

I don’t see these tools competing with each other. Swagger answers, “What should this API do?” Rentgen answers, “What does this API actually do?”
Those are different questions, and both deserve an answer.

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