Karate VS cats

This is why we need better tools which will give benefits for the added complexity. If you need to create both the feature files AND the code, it's just complexity with little benefits. But frameworks like https://github.com/karatelabs/karate or https://github.com/Endava/cats are hiding this complexity and remove the code layer entirely. Which, in my view, this is where you need to be in 2023, particularly for API testing.

- https://insomnia.rest/ - https://hoppscotch.io/ - https://github.com/karatelabs/karate - https://github.com/warmuuh/milkman

Congrats on the launch ! I'm the lead dev of [Karate](https://github.com/karatelabs/karate) and was wondering if you had come across it. I strongly agree that collaboration should be [via Git](https://www.karatelabs.io/first-class-citizens) and the IDE and traditional solutions fall short. I hope Karate's syntax passes your "memory friendly" test :) We get regular feedback is that it is easy to read and even non-programmers can pick it up. One thing I feel we do really well is chaining of HTTP requests. And we have plugins for [IntelliJ](https://plugins.jetbrains.com/plugin/19232-karate) and [VS Code](https://marketplace.visualstudio.com/items?itemName=karatela...).

Maintaining a tool like this as open-source is hard, all the best !

FWIW https://github.com/karatelabs/karate is 83% Java.

We use karate to test our fully integrated graphql backend. Has Gherkin language support.

Try Karate

Take a look at Karate.

Out of this frustration I've built: https://github.com/Endava/cats. It's for APIs, but mostly addressing exactly this case: don't use strings for everything, if you choose to use it though, make sure you add patterns for checking if things are valid, make sure you think about all the corner cases and all the weird characters that can brake you app, and so on.

If the API has an OpenAPI spec available, you can use: https://github.com/Endava/cats

This is why we need better tools which will give benefits for the added complexity. If you need to create both the feature files AND the code, it's just complexity with little benefits. But frameworks like https://github.com/karatelabs/karate or https://github.com/Endava/cats are hiding this complexity and remove the code layer entirely. Which, in my view, this is where you need to be in 2023, particularly for API testing.

I've built a tool specifically to test if these kind of characters will reach API backends: https://github.com/Endava/cats. My idea was that APIs should explicitly reject or sanitise input containing such characters.

Cats by Endava