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.
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.