What's missing from Hurl is snapshot testing. After using `insta` for testing APIs, I cannot go back.

Hi Hurl maintainer here, happy to answer any question and get feedbacks!

The main thing I find missing with hurl is an rc file.

Is that POST in the readme sending the password in the query params? Is this shorthand or literally adding them to the params?

I don't really feel the need for a curl replacement. In the past I've used httpie which is pretty slick but I end up falling back to writing tests in python using requests library.

Maybe I'm not the target audience here, but I should still say something nice I guess. It's nice that it's written in Rust, and open source tooling is in need of fresh projects ever since everyone started bunkering up against the AI monolith scraping all their work. We should celebrate this kind of project, I just wish I had a use for it.

If I want to open a modal & check something, could it simulate clicking on open modal button? Or is it first level for now (without any support for interactions / javascript magic)

This looks awesome. I've searched for something like this many times and made a half dozen half-hearted attempts to build it too. Great job!

this looks nice. is it possible to set a variable after a request and use it later in another request?

Can you have different environments or profiles or whatever, with different global variables?

Yeah love Hurl, we stared using it back in 2023-09.

We had a test suite using Runscope, I hated that changes weren't versioned controlled. Took a little grunt work and I converted them in Hurl (where were you AI?) and got rid of Runscope.

Now we can see who made what change when and why. It's great.

interesting tool !

première fois que je vois qqch de cool sortir d'orange.

For automated testing I use hurl, but my personal dev roadmap is to create another tool.

The deficiencies in huel with client state management is not easy to fix.

What I'd like is full client state control with better variable management and use.

For my last project I used Python to write the tests, which appears to work well initially. Dunno how well it will hold up for ongoing maintenance.

I am using it and I love it :)

Can you share "fixtures" amongst tests? For example, I wouldn't want to have to copy/paste the signup and login process for each type of user across hundreds of tests.

What about test isolation? Are people using something else to "prime" the service before/after running these tests?

Isn't that very similar to Jetbrains HTTP Client ?

This is interesting. I’m wondering how programmable this is. Would this project (or any similar ones) be able to POST a json payload with a field set to “now()”?

Is there any program code that is not based on plain text? Punch cards maybe? For the value of "plain text" that includes a programming language with its own syntax and grammar, like Hurl.

The one thing I never understood about the Hurl format is why the response status code assertion happens at the request section and not under the `[Asserts]` section. I wonder what the rationale behind that is.

So we are not doing telnet anymore?

One thing not really advertised about Claude Code is it makes all command line tools plain text/plain English.

“Get data from the last log entry in <file> and post it to <url>”

This is cool, but also genuine question why this over some scripting language that can easily do http calls as well?

I don’t think the DSL is significantly easier than a PL and it’s more limited to?

Is it because of raw speed or ease of reading the DSL?

I just started using hurl a couple months ago.

For my uses it's great that it has both test suite mode and individual invocation mode. I use it to execute a test suite of HTTP requests against a service in CI.

I'm not a super big fan of the configuration language, the blocks are not intuitive and I found some lacking in the documentation assertions that are supported.

Overall the tool has been great, and has been extremely valuable.

I started using interface testing when working on POCs. I found this helps with LLM-assisted development. Tests are written to directly exercise the HTTP methods, it allows for fluidity and evolution of the implementations as the project is evolving.

I also found the separation of testing very helpful, and it further enforces the separation between interface and implementation. Before hurl, the tests I wrote would be written in the test framework of the language the service is written in. The hurl-based tests really help to enforce the "client" perspective. There is no backdoor data access or anything, just strict separation betwen interface, tests and implementation :)

IntelliJ has had this "plain text HTTP" feature for a while. I'm wondering if it is backed by Hurl?

I think the idea is nice, but I am struggling for why I should use it. I write using Django, which has plenty of hooks for testing within the framework. Why switch to a tool which is blind to my backend and is going to create more work to keep in sync? At minimum, I lose the ability to easily drop into my debugger to inspect why a result went wrong.

There is probably something to be said for keeping a hard boundary between the backend and testing code, but this would require more effort to create and maintain. I would still need to run the native test suite, so reaching out to an external tool feels a little weird. Unless it was just to ensure an API was fully generic enough for people to run their own clients against it.

> It's somewhere between a curl script and Postman

Sounds a lot like Emacs' restclient-mode, and I can absolutely see the appeal for those which don't already have an Emacs session open.

I believe it's built-in to IntelliJ, just create a file with .https extension.