Looks like a DSL. I’m pessimistic about any DSL which is not built on top of a (“normal”) programming language. The typical trajectory of these is to start small, then start accommodating more use cases (adding variables, conditions and loops). It ends with an accidental programming language built on top of configuration syntax. Teraform and Puppet are examples. Hope to be wrong about hurl. Let me know if I’m missing something here.
Hi maintainer of Hurl here. It’s certainly something hard to balance. we had a lot of feature requests for incorporating kind of scripts inside Hurl (like JavaScript pre and post request). Because it’s hard, and it opens security issue, we don’t want to do this now. Personally, I also find this a bit awkward: you have a DSL tailored for HTTP with a syntax for incorporating JavaScript calls. Why not do a complete JavaScript test then?
I love this project and slowly converting my team to start using this for all our cache testing! My one favourite feature is the nifty thing where verbose mode prints out a usable curl command.
I was just looking into hurl. I wanted to see if I could use it for a mock server where we use the spec to define mock request and responses. Has anyone tried that?
Hurl doesn’t support that, but I had the same idea and forked their parser. It works, but I had three issues:
It gets pretty unwieldy to write your entire response in plaintext. It’s easier to write hurl requests, because you requests are typically fairly small. Even asserting properties on responses is easier than writing the whole thing down, especially as your responses start getting larger and more complex.
Given the above, if you’re not writing your responses by hand, there’s better solutions for mock servers out there, especially ones that proxy the real server and give you one-click setups to get mocks. So you don’t want to hand author mocks anyway.
For most things where you’d like to use a mock server, there’s alternatives like vcr that are just flat out better, and I eventually switched to those for the use cases where I wanted a mock server.
Hm, I don’t fully understand. I interpreted this in two ways:
An adapter that would convert requests stored by vcr into the hurl format: I don’t think that’s very useful, because vcr libraries (at least all the ones I know) already save the request/response in a human readable format. E.g. vcr.py saves them in YAML. I don’t see the need the use the hurl format here - the responses are often too large to be hand editable anyway.
Using a hurl-format mock server to intercept the request that vcr “records”: I don’t think that’s useful either, you can hand-write the vcr plaintext file if you’re so inclined, and you’d face the same challenges I mentioned before. But I think the real utility of vcr is that it stores exact request/responses that you hopefully got from a live server, which helps make your tests more “true to life”. Even with a mock server like wiremock I’d typically first proxy and record requests to ensure my handwritten requests weren’t too synthetic.
First one. How can you make requests if you don’t provide the url+headers+token? I was thinking specifically this: use hurl files to make requests to the actual server and then store the responses with a vcr adapter. Then you can turn that into a mock server for local development.
So you use hurl like normal, with urls and headers and assertions. Then we capture the responses and save them in whatever format we want. Then staple a mock http server that understands the saved responses format.
That’s a good point, but I don’t think I’d use that as much. If I’m working on the client, I’d do it by writing the client code, which make an “authentic” request, instead of writing a “fake” test in Hurl. That’s how I use vcr.py, for example: I write a test case which makes requests.
So I’d only use that if I’m working on an API server for which I want to publish a mock for my clients to use. IMO when iterating in development testing against a live server is much more useful, so I’d rather work on something that lets my client developers iterate with a live server instead of a mock.
I’m curious, though, what is your workflow? Where do you see this fitting into that?
The possibility of using it for stress testing is interesting. Not sure how much throughput it can get compared to k6, but nevertheless it’s another nice functionality for a great tool.
Hi maintainer of Hurl here!
When implementing parallel tests and –repeat options, we had in mind to go into k6 territory, with maybe a simpler tool (but as not complete as k6). I m really interested in feedbacks if someone is using Hurl for stress tests. One thing we need to implement is an option to rate limit the throughput (will be available in the next release)
Looks like a DSL. I’m pessimistic about any DSL which is not built on top of a (“normal”) programming language. The typical trajectory of these is to start small, then start accommodating more use cases (adding variables, conditions and loops). It ends with an accidental programming language built on top of configuration syntax. Teraform and Puppet are examples. Hope to be wrong about hurl. Let me know if I’m missing something here.
Hi maintainer of Hurl here. It’s certainly something hard to balance. we had a lot of feature requests for incorporating kind of scripts inside Hurl (like JavaScript pre and post request). Because it’s hard, and it opens security issue, we don’t want to do this now. Personally, I also find this a bit awkward: you have a DSL tailored for HTTP with a syntax for incorporating JavaScript calls. Why not do a complete JavaScript test then?
Yep. Tricky situation. Hope you will be able to navigate it. The pressure might increase.
This is awesome. I prefer hurl over postman and evangelize it whenever I can.
I have started experimenting with hurl for my functional API tests and these new features are just what I needed.
I love this project and slowly converting my team to start using this for all our cache testing! My one favourite feature is the nifty thing where
verbosemode prints out a usablecurlcommand.I’m wondering if Meilisearch couldn’t use Hurl for its tests. Looks easier to edit and modify than plain Rust. I’ll talk about that with the team.
I was just looking into hurl. I wanted to see if I could use it for a mock server where we use the spec to define mock request and responses. Has anyone tried that?
Hurl doesn’t support that, but I had the same idea and forked their parser. It works, but I had three issues:
I think you hit a great idea: vcr adapter for hurl!
Hm, I don’t fully understand. I interpreted this in two ways:
First one. How can you make requests if you don’t provide the url+headers+token? I was thinking specifically this: use hurl files to make requests to the actual server and then store the responses with a vcr adapter. Then you can turn that into a mock server for local development.
So you use hurl like normal, with urls and headers and assertions. Then we capture the responses and save them in whatever format we want. Then staple a mock http server that understands the saved responses format.
That’s a good point, but I don’t think I’d use that as much. If I’m working on the client, I’d do it by writing the client code, which make an “authentic” request, instead of writing a “fake” test in Hurl. That’s how I use vcr.py, for example: I write a test case which makes requests.
So I’d only use that if I’m working on an API server for which I want to publish a mock for my clients to use. IMO when iterating in development testing against a live server is much more useful, so I’d rather work on something that lets my client developers iterate with a live server instead of a mock.
I’m curious, though, what is your workflow? Where do you see this fitting into that?
I’m probably not describing it well but what you are suggesting is what I’m suggesting: hit a live server with hurl and save the responses.
The possibility of using it for stress testing is interesting. Not sure how much throughput it can get compared to k6, but nevertheless it’s another nice functionality for a great tool.
Hi maintainer of Hurl here! When implementing parallel tests and –repeat options, we had in mind to go into k6 territory, with maybe a simpler tool (but as not complete as k6). I m really interested in feedbacks if someone is using Hurl for stress tests. One thing we need to implement is an option to rate limit the throughput (will be available in the next release)