[HN Gopher] Hurl 4.0.0
___________________________________________________________________
Hurl 4.0.0
Author : jicea
Score : 410 points
Date : 2023-06-30 17:44 UTC (5 hours ago)
(HTM) web link (hurl.dev)
(TXT) w3m dump (hurl.dev)
| pmarreck wrote:
| 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?
| zgluck wrote:
| 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].
| mxuribe wrote:
| 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!
| jicea wrote:
| Noted, I'll try to make it clearer. We've been more explicit on
| the samples page [1]
|
| [1] https://hurl.dev/docs/samples.html
| letmeinhere wrote:
| 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.
|
| [1] https://github.com/pfeiferj/tree-sitter-hurl
| jicea wrote:
| 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.
| thunfisch wrote:
| 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.
|
| It's simplicity but powerfulness is amazing!
| smartmic wrote:
| Emacs enthusiasts have https://github.com/pashky/restclient.el
|
| I see some parallels to Hurl, but having everything inside Emacs
| is hard to beat, just thinking about using M-x jq-interactivly
| for json responses ...
| sergiotapia wrote:
| I will try to integrate this into our workflows. Hurl looks
| great!
| bityard wrote:
| This is one of the best examples of a modern Unix program I have
| seen:
|
| - It accepts input on stdin
|
| - It sends output to stdout
|
| - Does not appear to be littered with unicode emoji everywhere
|
| - It comes with man pages (and pretty good ones too!)
|
| - The hurl file extension is four characters long instead of
| three, thank goodness we're finally past MS-DOS compatibility
| concerns!
|
| This looks like something I might take seriously.
| sedatk wrote:
| > thank goodness we're finally past MS-DOS compatibility
| concerns!
|
| and VMS!
| EdwardDiego wrote:
| I never realised how much the emojis in my terminal annoyed me,
| until you mentioned this didn't have them, and I got excited.
| isanjay wrote:
| I used it briefly and found it very fast.
| krat0sprakhar wrote:
| > 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.
|
| Congrats on what seems like a great release
| jicea wrote:
| 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!
| TavsiE9s wrote:
| That's one of the reasons why I bookmarked it and will test
| it in various CI pipelines on Monday. ;-)
| wanderingstan wrote:
| 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_!
| convalescindrey wrote:
| 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.)
| jicea wrote:
| 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.
|
| [1] https://github.com/Orange-
| OpenSource/hurl/releases/tag/4.0.0
| debarshri wrote:
| 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.
|
| [1] https://adaptive.live
| sedatk wrote:
| Does it support OAuth flow out of the box, or do you need
| hardcoded tokens for that? (I checked the docs, couldn't find
| anything about it)
| debarshri wrote:
| To my best knowledge, it does not support oauth flow out of
| the box. This is also where we built some custom tooling
| around hurl.
| klysm wrote:
| 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
| smarkov wrote:
| 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.
| recroad wrote:
| The bigger problem here is that you have QA, not the lack of
| tooling.
| dijit wrote:
| The bigger problem here is that you have devs, devs make
| bugs.
|
| if you don't have devs there are no bugs, problem solved.
| convalescindrey wrote:
| If devs have to do QA themselves, many issues magically
| disappear.
| [deleted]
| dmw_ng wrote:
| 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
| convalescindrey wrote:
| > 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.
| dijit wrote:
| 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.
| convalescindrey wrote:
| [flagged]
| Quikinterp wrote:
| How big is your company and product?
| convalescindrey wrote:
| Anual revenue is in the ballpark of about $1bn-$5bn.
| vidyesh wrote:
| For a team using VSCode you can try the vscode-restclient[1]
|
| But really Hurl looks really interesting, being editor agnostic
| is the best solution for your problem, I agree.
|
| [1] https://github.com/Huachao/vscode-restclient
| kxrm wrote:
| 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.
| steve_adams_86 wrote:
| digikata's comment above suggests it is possible. It would
| be great to have something that isn't attached to the
| editor of choice.
| kxrm wrote:
| Indeed it does with https://hurl.dev/docs/capturing-
| response.html
|
| Also for VS Code integration specifically there is https:
| //marketplace.visualstudio.com/items?itemName=JacobPfe...
| ushakov wrote:
| There's also Step CI: https://stepci.com
|
| (I'm one of the authors)
|
| Hurl is brilliant though
| randomsofr wrote:
| 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.
| kbenson wrote:
| 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.
| jug6ernaut wrote:
| 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.
| imiric wrote:
| 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.
|
| [1]: https://github.com/apideck-libraries/postman-to-k6
| cmgriffing wrote:
| 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.
| TheBigRoomXXL wrote:
| 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.
|
| https://github.com/schemathesis/schemathesis
| digikata wrote:
| 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.
| jicea wrote:
| Hi maintainer here! Thanks a lot for the kind words!
| convalescindrey wrote:
| Great project!
|
| A comment I'd have is that it's quite hard to find out who
| authored this fine piece of software.
| insanitybit wrote:
| This is great, I love the native jsonpath support.
| Alifatisk wrote:
| Interesting project, might try it out!
| kristopolous wrote:
| Are there use cases beyond testing that anyone here has actually
| done?
| mxuribe wrote:
| 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.
| lfconsult wrote:
| I really do love this project . Using it in production for
| testing purposes. Great job guys.
| hiddew wrote:
| 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.
| hermanradtke wrote:
| 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.
| rrgok wrote:
| 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.
| klysm wrote:
| 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
| mcpeepants wrote:
| > 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
| kemotep wrote:
| At first, I thought this was the toy language Hurl[0] and was
| shocked the developer made it to version 4 so quickly.
|
| Really cool tool built with curl. Certainly could replace a bash
| script or two with something more robust.
|
| [0]: https://news.ycombinator.com/item?id=36393673
| compumike wrote:
| 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?)
|
| [1] https://heiioncall.com/blog/enhanced-api-monitoring-with-
| exp...
| bachrc wrote:
| 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 integration testing, this would be much more
| cleaner
| dgellow wrote:
| I learned today that Visual Studio 2022 has support for something
| similar with .http files: https://learn.microsoft.com/en-
| us/aspnet/core/test/http-file....
|
| Hurl seem to have way more features.
| isanjay wrote:
| And way faster
| bdcravens wrote:
| I've used the VS Code extension this feature was based on for a
| while.
| gossamer wrote:
| I have never wanted to hurl more than I do now. But in a good
| way. :-)
| klysm wrote:
| I have no idea what you are trying to say
| ISO-morphism wrote:
| To hurl means to throw forcefully, and is commonly used as a
| synonym for vomiting, c.f. "throw up"
| miki123211 wrote:
| 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.
|
| [1] https://httpie.io/ [2] https://github.com/ducaale/xh
| utybo wrote:
| I really like httpyac for this purpose: https://httpyac.github.io
|
| Pretty similar with JS scripting capabilities. Has great VS Code
| integration in addition to its CLI.
| brewmarche wrote:
| 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.
| jiehong wrote:
| Great job to the team! Hurl is growing rapidly!
|
| 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?
| bityard wrote:
| 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
___________________________________________________________________
(page generated 2023-06-30 23:00 UTC)