Group Details Private

Global Moderators

Forum wide moderators

3 Reasons to use Insomnia REST Client in your Exploratory API Testing

TLDR; Use a combination of tools to offset other tools weaknesses. Insomnia makes switching HTTP proxies easier than Postman when performing exploratory testing

In my recent HTTP REST API application testing I have been using a combination of tools:

  • Postman for interactive requirement and documentation based testing
  • Java and REST Assured for automating the API
  • Insomnia REST for more exploratory API testing

In this post I’ll describe, and show, how I do that.

A Basic Process Overview

In Postman I build a collection with my main requests and examples.

When I find a ‘thing’ and need to explore in more detail I move over to Insomnia.

I either export my Postman collection and imported into Insomnia as a Workspace, or I convert a Request in Postman to a cURL request using the code generation facility in Postman. I can then copy the cURL request from Postman and paste it into the URL bar in Insomnia which does a really good job of creating a request in Insomnia.

Insomnia makes working with API documentation easy as well since many of the API examples are presented in cURL I can copy and paste the examples into Insomnia for experimentation.

Why move to Insomnia?

I use Insomnia because the preferences dialog allows me toeasily feed Insomnia through an HTTP Debug proxy like Burpsuite or Owasp Zap.

Postman will now route traffic through a system hook proxy like Charles or Fiddler, but it can be a little more troublesome to feed Postman through a proxy, and certainly is not as easy to toggle between proxies without exiting the Postman app.

Often when I’m exploratory testing I’ll want to use different proxies e.g. Burpsuite and Owasp Zap have different filtering abilities and different Fuzzers, and I like the option of switching between them all without losing testing focus and restarting the app.

I also find the JSON filtering of result payloads in Insomnia quite useful.

Use tools in combination

I use tools in combination.

  • Collections in Postman
  • Data Driven testing from data files in Postman with the Runner and csv files
  • Exporting collections to insomnia for easier experimentation with requests through a proxy
  • Proxy for ‘extreme’ payload manipulation and fuzzing
  • Proxy for capturing the traffic and helping me document my testing

I don’t try to find the ‘one true tool’. I try to identify the strengths of each tool, and the weaknesses. Then figure out what I can do to augment the weaknesses with other tools.

You can see the tools in action in combination in this Youtube video:

posted in Feed de Blogs e Posts
Developer Experience: The Key to a Successful API

User experience is the key to adoption. If no one understands how to use your product, they won’t buy it. This is equally true in the world of APIs. Developers are more likely to adopt and stick with…

posted in Feed de Blogs e Posts
Code school : FREE WEEKEND

Todos os cursos disponíveis no período de 18 a 20…
Segue link:

posted in Geral
SmartBear Achieves Second Highest Score from Gartner in Mobile Applications Use Case

Earlier this year, Gartner released the Critical Capabilities for Software Test Automation Report. This report was created to help application and QA leaders, who are modernizing software…

posted in Feed de Blogs e Posts
RE: Como saber quais casos de testes executar em um sprint ?

1000 casos??
alt text

Já teve, em algum momento nessa vida a revisão do que tem?
Sobre a sprint, como já foi dito, cuide do que é novo e cuide do que o novo pode impactar…

posted in Geral
How to Protect Your IoT Ecosystem from CoAP Security Vulnerabilities

Many Communication Protocols Are Emerging to Satisfy the Unique Parameters of the Internet of Things Ecosystem. Recently, many IoT-based communication protocols have emerged to try and satisfy the…

posted in Feed de Blogs e Posts
How to Assess the Value of a Code Review Culture

In manufacturing, getting to an ROI is pretty cut and dry. What are the cost of the materials, how many products will that yield, and what can we sell it for? Calculating the value of a collaborative…

posted in Feed de Blogs e Posts
A brief update & AMA II

It’s been a while since I wrote something on this blog as you could say my life has been a bit complicated. In May this year whilst moving house my wife sadly suffered from a rare medical condition called necrotizing fasciitis. She spent two weeks in intensive care, had seven operations, spent a month in … Continue reading “A brief update & AMA II”

posted in Feed de Blogs e Posts
Code Health: Eliminate YAGNI Smells

This is another post in our Code Health series. A version of this post originally appeared in Google bathrooms worldwide as a Google Testing on the Toilet episode. You can download a printer-friendly version to display in your office.

By Marc Eaddy

The majority of software development costs are due to maintenance. One way to reduce maintenance costs is to implement something only when you actually need it, a.k.a. the “You Aren’t Gonna Need It” (YAGNI) design principle. How do you spot unnecessary code? Follow your nose!

A code smell is a code pattern that usually indicates a design flaw. For example, creating a base class or interface with only one subclass may indicate a speculation that more subclasses will be needed in the future. Instead, practice incremental development and design: don’t add the second subclass until it is actually needed.

The following C++ code has many YAGNI smells:

<table class=“my-bordered-table” style=“width: 613px;”>



<td style=“background-color: #cfe2f3; vertical-align: top; width: 607px;”>

<pre style=“background-color: #cfe2f3; border: 0px; color: black; margin: 0px; padding-bottom: 0px; padding-left: 0px; padding-top: 0px;”>class Mammal { …
virtual Status Sleep(bool hibernate) = 0;
class Human : public Mammal { …
virtual Status Sleep(bool hibernate) {
age += hibernate ? kSevenMonths : kSevenHours;
return OK;





Maintainers are burdened with understanding, documenting, and testing both classes when only one is really needed. Code must handle the case when hibernate is true, even though all callers pass false, as well as the case when Sleep returns an error, even though that never happens. This results in unnecessary code that never executes. Eliminating those smells simplifies the code:

<table class=“my-bordered-table” style=“width: 613px;”>



<td style=“background-color: #d9ead3; vertical-align: top; width: 607px;”>

<pre style=“background-color: #d9ead3; border: 0px; color: black; margin: 0px; padding-bottom: 0px; padding-left: 0px; padding-top: 0px;”>class Human { …
void Sleep() { age += kSevenHours; }





Here are some other YAGNI smells:

  • Code that has never been executed other than by tests (a.k.a. code that is dead on arrival)
  • Classes designed to be subclassed (have virtual methods and/or protected members) that are not actually subclassed
  • Public or protected methods or fields that could be private
  • Parameters, variables, or flags that always have the same value

Thankfully, YAGNI smells, and code smells in general, are often easy to spot by looking for simple patterns and are easy to eliminate using simple refactorings.
Are you thinking of adding code that won’t be used today? Trust me, you aren’t gonna need it!

posted in Feed de Blogs e Posts
[Webinar] The 2017 State of Testing Survey Results

What are your biggest challenges with GUI testing? What about testing against third-party APIs?  Is your team truly agile? These are just a few of the questions we had for QA professionals and…

posted in Feed de Blogs e Posts

Looks like your connection to Agile Testers was lost, please wait while we try to reconnect.