I tried very hard to convince the hoppscotch devs to adapt something like .http files so they could be stored in version control. Only a few tools get that right.
Sadly I don't think they never understood the actual goal of it. And just added github to sync to or something like that. Which isn't what I was looking for.
I use IntellIJ and the http client does it and it works very well. But sadly the rest of the http client is annoying just basic stuff like reading the response is always a few more clicks than I want and compared to Insomnia so much harder.
I'm not the parent poster. Your question assumes that Postman / curl / anything are used to test something. I generally use those kind of tools to explore an API and I write tests later if I use it or never if the team decides to use something else. After all a project defines very few APIs but consumes a lot of them from external entities, at least in the projects I'm working on.
I suggest you could try Hurl (https://hurl.dev). It’s a cli tool to send and test HTTP requests, in plain text.
As I’m one of the maintainer, I find it quite readable…
> I want something much simpler, so I use VS code with a "REST Client" plugin
I follow the same approach. Emacs, Verb[0] and org-mode. An alternative to Verb would be restclient.el[1] but I like Verb more because it works as an extension to org-mode which is great for documentation.
This is the way; if anything, your requests are in plain text in your version control right next to your code, instead of in a proprietary format or intentionally hidden away in a cloud service (postman).
Postman collections are just JSON, but that JSON is impenetrable to humans and merging algorithms. Rest client shows how a good file format can be a huge advantage.
As a small dev team we have a workflow to rapidly author tests integrating our internal and external graphql + rest APIs.
These tests can be run, tweaked and parameterized in various environments from the GUI, and then imported into our CI system with Newman. Its a low code approach that's saving us time so I'm grateful of the features we are getting (for free) with Postman.
Would you not be better off making those tests in your programming language of choice, which is likely the same as the code under test, be it Python, Node.js with Mocha, Ruby, Java or C# ?
Or even avoid programming languages as much as possible. Most of my API tests are done with curl and jq. (Which I blogged about here: https://lambic.ca/blog/api-testing-with-curl/)
I think you're actually testing with bash (and included tools) there.
Which is fine, bash is a programming language of sorts (I see "if" statements!), and you can store the tests in text files in git. If those are the tools that you like to use, and it works, great.
That's why I said "as much as possible". I keep the bash scripts as linear as possible so they are "scripts" rather than "programs".
We started out using cypress, which I was convinced was the wrong tool for testing APIs so I switched to this approach, which sped up our CI deployments significantly.
Yeah, I have been using httpie (which offers a better DX) in similar fashion.
It also pairs well with (n)vim - I can just run :.!http whatever and have the response injected into a vim buffer where I can inspect or slice and dice the json with my usual vim workflow.
For testing an API layer, whose different API microservice implementations might be in different languages, and/or in languages your API test automation team don't understand, then that probably wouldn't work well. Why do you think it would?
I meant to say, what is the case for Newman over "pick a programming language that you like and know, and write the http tests in that" ?
It was my assumption that the people writing the APIs were also writing the tests, so they would prefer the familiar language.
If you have "different languages" in play, you get to choose one of them for tests. I've seen it happen that a language is chosen for test that is not in use in the API's at all. It's only "likely" the same language, as I said above.
If you have a isolated "API test automation team" then it sucks to be you, but the language choice would be on them, wouldn't it? I don't think that I implied otherwise.
> If you have a isolated "API test automation team" then it sucks to be you, but the language choice would be on them, wouldn't it? I don't think that I implied otherwise.
You said the tests should be in the implementing languages
On the "sucks to be you" - I have test automation folk in the team delivering software alongside everyone else as a cross-functional team; I just used the word "team" loosely to mean "the group of people whose job it is to do certain levels of test automation".
> It was my assumption that the people writing the APIs were also writing the tests, so they would prefer the familiar language.
The point I'm making is makes sense for unit tests, semi-unit tests, and possibly also for lower-level API tests (e.g. API testing an individual service), but when you have to test functionality across services, you might well not want to pick a technology that the service(s) under test were built in.
> You said the tests should be in the implementing languages
No, I did not say "should", I said that they would "likely" be in the same language, for reasons given above. Yes, I get that there are also reasons to deliberately choose otherwise.
> but when you have to test functionality across services, you might well not want to pick a technology that the service(s) under test were built in.
Great. For the third time, what is the case for Newman being that technology, over a well-known programming language?
For me it's because people already know and are already using Postman. We already author collections for services that other devs in the company reference when using our APIs.
Sure we could write the tests in python or whatever, but everyone is already using and likes Postman for the most part. And replacing the postman collections that people use for reference with a folder of scripts I don't see going over well.
I'd personally prefer something like https://hurl.dev where you have a readable file in source control, but that's not a battle I'd win at this point.
Yeah it's turning it into a tool not for developers, or for very poor developers afraid of code.
There might be a market though for people "building APIs" through no code/low code tools like zapier and ifttt. Then I suppose they can sorta test their low code contraptions with this without knowing much about coding.
IDK if I am a "poor dev" but I find the Postman interface extremely complex and confusing. There are tabs, dropdowns, logins, collections, modes etc. Getting it to work is a chore.
A http request written entirely in a text file is IHMO far clearer.
The syntax of this plugin seems very similar to dot-http[0] and IntelliJ's REST client. Super interesting. Would be really interesting to have these three fully compatible with each other.
I want something much simpler, so I use VS code with a "REST Client" plugin: https://marketplace.visualstudio.com/items?itemName=humao.re...
Fundamentally, IMHO, a very complex and full-featured manual testing tool is a liability, as it will lead you away from test automation.