> Hurl is a command line tool powered by curl, that runs HTTP requests defined in a simple plain text format: <code sample>
This is how every new version announcement should start! I'd never heard of Hurl before and that intro + code sample on top instantly made me want to install and try it out.
Hi, maintainer of Hurl and avid reader of Hacker News for years. I've noted every advice for presentations (put a sample of your language asap, explain your concept every time succinctly, etc...). I've tried to put it in practice on hurl.dev so thank you for noticing it!
Amen. Far too many announcements and readmes jump right into installation requirements and “we’ve fixed X, Y and Z” but never actually tell you what the thing is!
A changelog is supposed to tell you what has changed.
A general greeting/landing page is supposed to tell you what the thing is.
Trouble is if a link to a changelog is submitted to HN. Most people who don't know what the thing is click on it, have no clue what they are looking it, close it again and then downvote the submission.
Submissions for not-widely-known stuff should be a landing page, not a changelog page.
(In other words, this hurl page is kind of a mix between these two which is odd and arguably misusing what a changlog / news announcement page should be.)
We've a more "classic" changelog in GitHub [1], I see the blog post as an editorial view of the changelog: highlights of main features/changes with some context.
What irks me is when the project description focuses on "Updog is written from scratch in Deactivated Typeflange" or whatever. So many github readme's where I have a pretty good idea about why the devs chose the language and toolchain they chose but zero idea of what the project does and why I might want to use it.
Happy to notice the "Locate the logo on top left corner and click" works in this case! I'm immediately forward to a page that provides exactly what I need.
Please make this the industry standard for testing APIs.
I'm tired of having to look at Postman screenshots sent from QA. I'm tired of having to wait for them to press Send once I've implemented a fix. I know they're tired of waiting for me to do that, too. Hurl is something both the devs and QA can speak and write. It can be automated and a part of CI. It makes communicating expectations straightforward. It can be chucked along with PRs as a starting point for QA. I don't see a reason not to use it wherever possible.
I have been using it for API testing manual and in CI of one of our services and it's been very nice. You can basically put a series of http exchanges for a workflow per hurl file and get a nice test suite that also checks directly into git.
I use the vscode-restclient and my primary reason is the conversational flows you can build against an API. Does Hurl support this? If so I would absolutely switch. All I would need to complete the experience is a plugin to do highlighting and integration with the Hurl files.
Have you tried https://k6.io/ ? (Full disclosure: I'm one of the maintainers.)
It allows you to write load/performance tests in JS, commit them to your repo, easily automate them in CI, send metrics to several backends, use protocols besides HTTP, with a modern CLI, and many more features.
There's also a Postman-to-k6 converter[1]. The conversion might not be perfect, but it will give you a head start.
Note that the k6 philosophy is for developers to write these tests, similarly to how you write unit/integration tests, and to break the classic QA-dev cycle.
I don't want to steal Hurl's thunder, it does look great, but it's limited in features compared to existing peformance testing tools, and I'd personally rather write tests in a programming language, than in a bespoke text format.
> but it's limited in features compared to existing peformance testing tools, and I'd personally rather write tests in a programming language, than in a bespoke text format.
I’d hardly call hurl’s config bespoke, it basically amounts to HTTP codes and some header stuff, which basically everyone is familiar with.
From personal experience a couple of weeks ago I needed some http tests. I got a CI-ready Hurl config working on some endpoints for work sorted within like, 5 minutes of downloading it. In comparison I opened the page for K6, saw the “write tests using JS” and basically noped out immediately,
That's fair, and k6 is not for everyone. JS was chosen as it's a popular language with a large web ecosystem, but the tool itself is written in Go.
That said...
> I got a CI-ready Hurl config working on some endpoints for work sorted within like, 5 minutes of downloading it.
I'm obviously biased, but I'd argue that k6 is equally easy to get started with. Take a look at the docs[1].
> I’d hardly call hurl’s config bespoke
But it is. It has a unique syntax, and no other tool uses it, AFAIK. I'm not saying it's not simple or easy to understand, but it's not as expressive as a programming language. Which is fine if your tests don't require any logic, but from experience, in order to simulate accurate real-world traffic, which you probably want when writing a load/performance test, you do need some logic, different scheduling options, a way to process and analyze the metrics, etc.
I don't want to turn this into a versus battle, as there is a place for tools such as Hurl, ab, and wrk to coexist with tools like k6 and Locust. I just wanted to mention it as an option for anyone who hasn't heard about it, as any personal biases aside, I do think it's a great tool.
Yeah, I did they start off with JS shenanigans, including importing packages, which immediately makes me concerned I’m going to have to deal with JS packaging dumpster-fire. There’s then one line of CLI args, followed by even more JS boilerplate.
> in order to simulate accurate real-world traffic, which you probably want when writing a load/performance test
I think the mismatch here is that Hurl is closer to being a http testing tool, not a load-testing tool, so most of these features are unnecessary.
> It has a unique syntax, and no other tool uses it, AFAIK.
Character for character, most of this is bog-standard http verbs, a url, and an html path string. The Jetbrain HTTP tool also sports very similar interface, and I believe there’s a VSCode plugin somewhere that does a similar thing.
I think you're mistaking k6 for another tool. k6 has only supported writing tests in JS. There are several other tools that are better suited for this single URL use case: ab, wrk, even Hurl. I doubt this will ever be supported in k6, since the focus is on scripting test logic, not firing off requests to a single URL (though this is certainly possible with a simple script).
I personally like the approach of defining things via an OpenAPI and then using Dredd to validate the spec against itself.
Even for tools that generate the spec from source code, it is usually still possible for user error to define the metadata for an endpoint incorrectly. Dredd catches that.
I also think that validating an API against it's OpenAPI schema is a great methodology. You should checkout schemathesis, it's fantastic for doing that.
I was just looking at this. We might use it at my company, but i was wondering, is this funded? Or is this just an open source side project for you guys.
Not that I necessarily think it's best to stay with Postman, but have you looked at newman, which is the CLI runner for postman configs? We had postman as a test suite for something (which is more an API than an app), and I got tired of having to deal with setting up extra steps to test and of exporting the postman config to save in the repo, so I put newman on the test system and just run against the config directly in the test environment and check the output.
I don't necessarily recommend editing the postman config json directly to set up new tests as it's a PITA, but it's generally what I do so I don't need to keep importing and exporting it with Postman.
A tool designed for working with on the shell is likely better than what I'm doing with newman (since the config is not the most accessible), but it also meant I didn't need to rewrite a bunch of existing tests and verify they actually did the same thing.
The problem Newman/postman have is the same for every GUI based testing application. They almost always produce non human readable config files. Making any kind of code review of such changes at best extremely painful and at worst impossible.
IMO any testing tool that does not save it's test classes in a human readable format is DoA.
Honestly that sounds like making pilots build aircraft engines.
these are different disciplines that deserve to be done well.
Maybe I am biased because I spent the last 10 years in gamedev, or maybe this is another push to make devs do basically everything tech related: but if a developer tells me a feature is done I always look to QA for a nod.
That nod rarely comes, the feature is not done, the developer merely got it to work on their machine.
Then your developer should learn that "done" means more than "works on their machine".
The difference between devs and dedicated QA people is that devs know the dark corners of the implementation. They know the edge cases and scenarios that they struggled with getting right. That's where most testing focus has to be. QA doesn't know any of that. They can play through some scenarios that are the expected ones from the spec, perhaps have some hunch of what could be the tricky cases, but they don't actually know.
I love seeing all those downvotes for my GP comment. That's all the people working at companies where stuff that devs feel is below them is dumped on QA people, which is the main reason my company is well-known for shipping top quality (without having a QA dept) while our competitors struggle with quality (despite having a QA dept). That's all the evidence I need to back up my claim.
If this happens to be a reference to Microsoft, their famous laying off of qa people has been regarded as a disaster by everyone outside Ms, with windows update quality dropping off a cliff.
And I believe it's hard to do this kind of thing as an afterthought. If your whole engineering culture is built around having a QA dept then just firing that dept is obviously going to have disastrous consequences.
never underestimate the ingenuity of a good QA person. "app freezes while triple-clicking About button while changing wifi network when storage is 89% full and screen reader is enabled"
it's the same with good security folk. sure you can pretend you'll catch 100% of issues, but it's a delusion, good security or quality testing is a totally different mode of thought
> never underestimate the ingenuity of a good QA person. "app freezes while triple-clicking About button while changing wifi network when storage is 89% full and screen reader is enabled"
If such feature interactions matter then your application has bigger problems than a QA department.
> it's the same with good security folk. sure you can pretend you'll catch 100% of issues, but it's a delusion, good security or quality testing is a totally different mode of thought
Oh I'm not saying that good QA isn't a valuable skill! Of course it is, it doesn't just happen on its own. What I'm claiming is that it's a skill that should be employed as close as possible to the creation of the thing that it's assuring the quality of. So, ideally within the developer themselves.
Same thing with security. You will have a terrible security in your product if you first design and implement it and then put security in there as an afterthought by a dedicated security team. Ideally it's been at the table from day 1. So, a good security team works on educating your devs to do things right from day 1. Just like QA.
> If such feature interactions matter then your application has bigger problems than a QA department.
QA doesn't exist to check that your crap architecture solves the problem. They're there to be the skeptical person in the chain of custody from developer to production. The old adage "you can't test quality into software" exists for a reason. It's true. And you're right that it's the wrong architecture. But that's dismissing the very real purpose of QA which is to catch these kinds of bad architecture problems by testing for conditions that the dev team possibly didn't consider during development. QA is also there to make sure you're not making any unfounded assumptions about the context the software exists in.
To the extent you actually care about checking all of your assumptions and not just the ones you're cognizant of, QA is very useful.
Speaking of command line HTTP handling, my favorite tool for that is Httpie[1], or rather its faster Rust rewrite, XH[2]. It lets you issue HTTP requests from the command line with much nicer, more HTTP-like syntax than CURL and without the need to learn so many switches. If you already know curl well, it probably won't be of much use, but it's far, far more intuitive for casual use.
We at Adaptive[1] extensively use hurl.dev to automate our testing. All our internal product flows are tested via hurl. It is the best thing that we have ever implemented in our org to stabilize the product. Everytime before we deploy, we run bunch of automated tests written in hurl, for onboarding, signups, critical flows etc. That are containerized and can run in parallel. We have been building internal tools around hurl.dev too.
I really would recommend this tool. Nice thing is even analyst and business users can build these tests as it is fairly easy to pickup.
It seems reasonable to not support all the different auth schemes though. There are so many implementation quirks that it would be a huge burden to do that as part of the hurl project
I've been following hurl for sometime. Where it shines from others is that it has its own DSL For testing. It is not only to make http request, but to assert response and capture data. Having said that, and hoping the maintainer is reading this: please please make it such that assertion can passed to an external script. Why am I asking this? Because, an example, you cannot still assert that a property in a collection of items all have the same value (ex.: all titles should be XXX without using nth selector or make it possible to do nth = * ). And proving a DSL for all use cases is kinda huge effort. Would be great to pass the the output of jsonpath to jq for example and if that returns true, the test pass.
The DSL would slowly creep to a Turing complete general purpose language so I agree that invoking external scripts seems reasonable. The could be quite a can of worms though because it makes the files less hermetic
what if the script was inline in the DSL? e.g. some syntax for opening a script “block”, with an annotation of the command to exec or pipe the script into
One question if someone knows: while testing an endpoint, authentication is always needed.
Having written the authentication in 1 file, how can I import this file at the beginning of every other file that requires authentication and the associated token?
It doesn't look like Hurl has any functionality for inclusions, macros, and the like. I'm not sure those would be the best way to store and use secrets anyway. But the docs say you can pass variables into hurl files via command line args and through the environment: https://hurl.dev/docs/templates.html
httpyac is also very compatible to .http support in JetBrains IDEs. JetBrains also offers a free CLI tool to generate jUnit test reports from .http files.
Hurl and it's test cases have been awesome at our Ops team. We're managing an autogenerated config for hundreds of complex webserver rules, and we've been able to (auto-)generate hurl test cases for every single rule and test them in both CI and the actual infrastructure after deploying.
This looks like a great tool to put in charge of regularly testing your site performance in a dashboard or incorporating into CI somehow.
Has anyone done anything like this as, say, a Github Action, in a workflow? I see that there is this https://github.com/marketplace/actions/install-hurl-cross-pl... but I'm not sure how it would look in such a use case- a "performance test" stage perhaps? with logging over time to some other service?
I feel like DSL is becoming obsolete these days in favor of general programming (e.g. Python). I really like Hurl but every time we use it we revert back to simple Python because something is slightly off or missing (they just added XPath support) or different and just writing up Python script is easier and more powerful. Onboarding people on Python test suite is much easier than teaching them whole DSL that they'll be using few times every month.
Is anybody else wary of a new grammar with no transformer available to/from anything more common (e.g. json/xml)?
I did find [this][1] tree-sitter parser, so that's a start, but it seems like writing these would be a lot easier to write these if the interface was a library in a general purpose language or a subset of json.
You can export Hurl file to JSON with hurlfmt. We've done this so you can go to another tool if you prefer and convert your tests. It may be a start. The Hurl parser is also available as a library through Rust crates.
Feedback: The homepage (https://hurl.dev/) doesn't really make it clear - is this an interactive tool or not?
If I understand it correctly, you're supposed to save that example as a file and run 'hurl example.hurl'. It would make it easier to understand if that sample code box had a headline saying e.g. [example.hurl].
I'm not the author, but after reading the manual (https://hurl.dev/docs/manual.html), it seems to me that the tool can be used both ways. That being said, i think the value of this tool (beyond a tool like curl, wget, etc.) is that its likely preferable to base usage on non-interactive use, or at least leverage the tool via its .hurl files. While i actually like the succinctness of the homepage in describing this tool, you're not wrong that the author could have added an additional sentence stating the interactive or not point slightly more clearly. Even still, the documentation is much better for this tool, than other tools that i have seen. For this i'm thankful!
Would it be more clear if we put line numbers in Hurl file snippets (even on the home)? I like the simplicity of our docs, but I can understand that it isn't clear how to use it. By the way, that's why we have put an asciinema animation on the home page, starting with `vim my_file.hurl`
hurl is great, glad to see it's being improved on. I wrote a small wrapper around it a while back to be able to re-use some auth stuff in different requests, but a simple "include <file.hurl>" would be an awesome addition in a future release.
Getting started with it was way easier than figuring out postman or any of the many other http testing frameworks with their own languages/dsls
Hurl looks like a game changer for me. The fact that there’s a session shared within a file means as a backend dev I may be able to trivially eliminate the browser from my dev flow (without a bunch of annoying scripts). I’m on vacation and can’t wait to try this back at work.
Nice QoL improvements. Hurl is my go-to for any Postman-like problem. It is much easier to maintain and share hurl script then it is for me to share a Postman json blob.
Can anyone who's used hurl explain whether there are any use cases where something like Postman can do something hurl can't or can do it much better? I haven't used Postman very often previously but at work my role may change to require much more testing work (that many in the industry would have traditionally used Postman for).
I can't speak for Postman, but at work we use Hurl intensively in our CI/CD. Test files are commited, and using comments in Hurl files serve as a documentation of requests workflows.
Another Hurl use case is, instead of testing APIs, you want to download datas. Like curl, Hurl can output an HTTP response body. Unlike curl, this response can be the last one of a complex workflow (data behind login for instance, you need to capture data from one request and inject in another request like CSRF tokens).
Never heard of this! I will definitely take a look if this can replace some handwritten bash curl-based test scripts to validate HTTP-level interactions. The combination of documentation and testing in a single text file looks promising.
Actually done? No. However, one use-case that i couild think of - beyond testing - would be to modularize some dev work. For example, maybe i have a junior dev who knows some http, but not experienced enough to be a lead dev, or something like that. I could give the junior dev a task like draft up some tech spec...Or, i could have them use their basic http skills and craft Hurl files...one for each function that will inevitably be a function in code...either to be done by a more senior dev, or who knows, maybe this same junior dev could eventually learn to code based on their own hurl files...which someone else might call pseudo-code (or pseudo-code in tech docs)...which eventually gets turned into production code...and those same hurl files can also be turned into test cases.
Anyway, for me, hurl looks like an evolution of curl...which makes sense since its built off of curl (https://hurl.dev/#powered-by-curl). So, for uses-cases that might reach beyond curl, that's when i might reach for hurl as well. No doubt, there could be other use-cases for hurl.
As other people, I really think this is a great piece of software, but I didn't ser any way of reusing hurl file in anothers? For intégration testing, this would be much more cleaner
Pretty interesting! It makes me wonder, would anyone want a hosted version that runs checks against your production API endpoints / websites periodically? We have these basic capabilities (for example, assert headers, status code) as part of Heii On-Call’s HTTP outbound probes [1] but a more powerful assertion syntax might be interesting for some use cases. (Or are the basics good enough for Continuous Monitoring? And the advanced assertions more interesting for CI?)
This is how every new version announcement should start! I'd never heard of Hurl before and that intro + code sample on top instantly made me want to install and try it out.
Congrats on what seems like a great release