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.
You can build tests in it that can be run in automation via Newman.