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.
https://github.com/hoppscotch/hoppscotch/issues/870#issuecom...
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 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.
[0] https://github.com/federicotdn/verb [1] https://github.com/pashky/restclient.el
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).
https://marketplace.visualstudio.com/items?itemName=rangav.v...
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.
You can build tests in it that can be run in automation via Newman.
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.
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.
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?
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.
No, you were saying they'd be better off doing it. I was saying why that might not be the case.
I'm still not sure of this case. perhaps you could explain it in a bit more detail?
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.
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.
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.
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.