[HN Gopher] Hurl: Run and test HTTP requests with plain text
___________________________________________________________________
Hurl: Run and test HTTP requests with plain text
Author : flykespice
Score : 411 points
Date : 2025-06-20 03:55 UTC (19 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| laerus wrote:
| What's missing from Hurl is snapshot testing. After using `insta`
| for testing APIs, I cannot go back.
| porker wrote:
| Is this https://insta.rs/? What are the benefits you've found
| with snapshot testing?
| laerus wrote:
| Greatly reduced boilerplate. Diffing snapshots and providing
| previews to accept or reject changes is also more robust and
| user friendly.
| whilenot-dev wrote:
| What's your value proposition for snapshots and why can't that
| already be fulfilled with full body checks?
| https://github.com/Orange-OpenSource/hurl?tab=readme-ov-file...
| laerus wrote:
| Snapshots diff current with previous output and I only have
| to accept or reject the diff. I don't have to write the
| expected response myself. Snapshots can also stub out parts
| of the response that are not determistic.
| adelineJoOs wrote:
| > Snapshots can also stub out parts of the response that
| are not determistic.
|
| TIL! The way I knew to do it was to have a mock
| implementation that behaved like the real thing, expect for
| data/time/uuids/..., where there was just a placeholder.
| Snapshot tests being able to "mask" those non-deterministic
| parts sounds cool!
| adelineJoOs wrote:
| tbh, that seems pretty close to what I would call snapshot
| testing already. What people usually do with it is using it
| for more broadly compared to API testing (for example, I
| currently use it to test snapshots of a TUI application I am
| developing) - i.e. you can use it whenever your test is of
| the form "I have something that I can print in _some_ way and
| that should look the same until I explicitely want it to look
| differently in the future ". There are a bit more bells and
| wizzles - For example, it is nice that one does not have to
| write the initial snapshots oneself. You write the test,
| execute, it creates the resulting file, then you review and
| commit that - handy little workflow!
| CommonGuy wrote:
| We are working on snapshot testing for Kreya, expected to come
| in August. You might want to check it out :)
| jicea wrote:
| Hi Hurl maintainer here, happy to answer any question and get
| feedbacks!
| jiehong wrote:
| Thanks a lot for maintaining it!
|
| Where do you see hurl in the next 2 years?
| jicea wrote:
| Obviously better IDEs integration, support for gRPC,
| Websocket would be very cool.
|
| A favorite of mine is to be available through official `apt`:
| there has been some work but it's kind of stuck. The Debian
| integration is the more difficult integration we have to
| deal. It's not Debian fault, there are a lot of documentation
| but we've struggled a lot and fail to understand the process.
|
| [1]: https://github.com/Orange-OpenSource/hurl/issues/366
| akdev1l wrote:
| Looks like you don't have Fedora package either
|
| If I find time I could throw a spec file + ci/cd workflow
| to get you going that way too
| hiddew wrote:
| Hurl is underappreciated for writing nice and maintainable
| HTTP-level test suites. Thanks for the tool!
| gavinray wrote:
| So, myself and many folks I know have taken to writing tests in
| the form of ".http" files that can be executed by IDE
| extensions in VS Code/IDEA.
|
| Those basically go in the form POST
| http://localhost:8080/api/foo Content-Type:
| application/json { "some": "body" }
|
| And then we have a 1-to-1 mapping of "expected.json" outputs
| for integration tests.
|
| We use a bespoke bash script to run these .http file with cURL,
| and then compare the outputs with jq, log success/failure to
| console, and write "actual.json"
|
| Can I use HURL in a similar way? Essentially an IDE-runnable
| example HTTP request that references a JSON file as the
| expected output?
|
| And then run HURL over a directory of these files?
| xnorswap wrote:
| I like this approach.
|
| Is your expected.json the actual response body, or is it an
| object containing body, status, header values, and time-
| taken, etc?
| gavinray wrote:
| It's only the response body, but that's due to not having a
| usecase to validate headers or status code.
|
| I really like it because it serves 3 purposes:
|
| - API docs/examples that you can interact with
|
| - Test cases
|
| - Manually invoking API endpoints when working on the
| underlying code, in an iterative loop
| digikata wrote:
| You can use hurl in this way. I have projects with a test
| directory of hurl files, one hurl file per test case. The
| cases can run one or more http requests. The hurl file can
| reference external files, capture values from responses for
| subsequent requests, validate status and outputs. Hurl has
| various test runner modes and will optionally output overall
| test results in various parsable formats if you have a larger
| reporting framework that you would like to hook into.
| gavinray wrote:
| That's great to know! Do you have an example on-hand by
| chance?
|
| If that's possible, I guess the only thing I'd request is
| interopability with the REST Client ".http" files that VS
| Code/JetBrains IDE's support then.
|
| _UPDATE:_ Found it, looks like you can do it via the below
| POST https://example.org/api/tests Content-Type:
| application/json file,insert_user.request.json;
| [Asserts] body == file,insert_user.expected.json;
|
| So that just leaves the IDE integration bit.
| LadyCailin wrote:
| Can you organize with the VSCode rest client folk(s?) to come
| up with a standard for http files?
| airstrike wrote:
| Arguably off-topic but I just want to say few naming choices
| give me more satisfaction than Hurl
| nikeee wrote:
| I use Hurl for some time now and even contributed. What are the
| current chances for getting some form of includes?
| chvid wrote:
| Looks a bit like this:
|
| https://marketplace.visualstudio.com/items?itemName=humao.re...
|
| Which is a banger VS Code extension for all sorts of http xyz
| testing.
| krisgenre wrote:
| IntelliJ has one too https://www.jetbrains.com/help/idea/http-
| client-in-product-c...
| 7d24cbd0556f442 wrote:
| neovim has one, too! https://github.com/rest-nvim/rest.nvim
|
| (After I have seen the IntelliJ one from a colleague I was
| searching for one like that in neovim. That's the best one I
| found. It's not perfect, but it works.
|
| Edit: The tool from OP looks very neat though. I will try it
| out. Might be a handy thing for a few prepared tests that I
| run frequently
| vyskocilm wrote:
| https://github.com/mistweaverco/kulala.nvim is an another
| restish (it can do gRPC to) plugin for neovim. It is intended
| to be compatible with a Jetbrains as much as possible.
| jiehong wrote:
| Yep, just editor independent which is a huge deal IMO
| lowwave wrote:
| there is also Bruno and Bru seems quite similar this:
| https://docs.usebruno.com/bru-lang/overview
|
| It is targeted toward more postman crowd though. May not be
| as lightweight.
| LadyCailin wrote:
| It's not nearly as lightweight, and one of the major
| dealbreakers for postman and equivalents (even ignoring all
| the drama with postman) is that you have to import and
| export the data in the client in order to get some text
| file you can just commit to repo. For my team, that's a
| dealbreaker, because it means that people write entire
| suites of stuff, and never commit them, meaning other
| people end up doing the same work over and over.
| argentinian wrote:
| In Bruno you don't have to import or export to get a text
| file.
| LadyCailin wrote:
| Ahhh, ok. I think I'm thinking about Insomnia, which is
| basically (in fact?) a fork of Postman. Anyways, that
| fact is what made Postman a dealbreaker for me, even
| before the drama. Another thing I like about Rest Client
| is that the configuration is just a text file, so bearer
| token etc can be updated via script that runs in a loop.
|
| Rest Client has a few cons though, like request chaining.
| argentinian wrote:
| In Bruno the config also is just a text file.
|
| I was using Rest Client and was very happy with it, but
| once I needed Rest Client to use my computer's NO_PROXY
| env variable to avoid using the proxy for a certain url,
| and I found it was not possible to do that with Rest
| Client. That's the only reason I had to look for an
| alternative tool. After an analysis, I liked Bruno and
| Hurl. I didn't try hurl yet.
| mcescalante wrote:
| yep, I've played with Hurl and find it nice but recently have
| been leaning into the .http stuff more. IntelliJ has it built
| in, there's the plugin you linked, and then for CLI i've used
| httpYac. No "vendor lock in", really easy to share with copy &
| paste or source control.
| gotimo wrote:
| +1 On HttpYac, it's been really nice to get started with and
| growing into a more powerful API testing suite over time
| davidcalloway wrote:
| The main thing I find missing with hurl is an rc file.
| jicea wrote:
| If you're thinking about `--netrc` like curl it's already here
| [1]. If you're thinking about a proper Hurl config file, it's
| coming!
|
| [1]: https://hurl.dev/docs/manual.html#netrc
| the_arun wrote:
| Isn't this similar to HTTP Client tool available for IntelliJ? -
| https://www.jetbrains.com/help/idea/http-client-in-product-c...
| resonious wrote:
| Similar perhaps but not an IDE plugin.
| HatchedLake721 wrote:
| It's available separately too
|
| https://blog.jetbrains.com/idea/2022/12/http-client-cli-
| run-...
| zoidb wrote:
| This looks great, would definitely use it for testing if
| websocket support ever gets added https://github.com/Orange-
| OpenSource/hurl/issues/1096
| antisceptic wrote:
| 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.
| ankitrgadiya wrote:
| I see it more as a Postman replacement than curl. When I'm
| working on a set of APIs, I can quickly write a Hurl file with
| different combinations that I'm working on. There are usually
| editor integrations to run individual requests. Then I can
| share the same Hurl file to my team or commit it in the repo.
| tra3 wrote:
| Check out tavern if you're in python-land. Pretty pleasant way
| to write declarative API tests.
| jicea wrote:
| The POST in the README is going to send the params in the
| request body "url form encoded" like a form in a web page.
| There are more samples on the doc site [1].
|
| Regarding curl, Hurl is just adding some syntax to pass data
| from request to request and add assert to responses. For a one
| time send & forget request, curl is the way, but if you've a
| kind of workflow (like accessing an authentified resource) Hurl
| is worth a try. Hurl uses libcurl under the hood and you've an
| option `--curl` to get a list of curl commands.
|
| [1]: https://hurl.dev/docs/samples.html
| mrcarrot wrote:
| > The POST in the README is going to send the params in the
| request body "url form encoded" like a form in a web page.
|
| Is there a different POST request in the readme or are you
| saying that this example is going to send the "user" and
| "password" params in the request body?
|
| > POST https://example.org/login?user=toto&password=1234
|
| That seems really surprising to me - how would you then send
| a POST request that includes query string parameters? The
| documentation on form parameters [1] suggests there's an
| explicit syntax for sending form-encoded request parameters
|
| [1]: https://hurl.dev/docs/request.html#form-parameters
| jicea wrote:
| Ah sorry for both, the README sample is here from the start
| (4 years) ago that I didn't take time to read it with a
| fresh eye: POST
| https://acmecorp.net/login?user=toto&password=1234
|
| In the README is doing a POST request with user and
| paasword parameter in the URL. POST
| https://acmecorp.net/login [Form] user: toto
| password: 1234
|
| Is a more traditional POST with user and password in the
| body. Probably going to update the READMEs sample Issue
| created here [1]!
|
| [1]: https://github.com/Orange-OpenSource/hurl/issues/4151
| the_arun wrote:
| 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)
| jicea wrote:
| Hurl works only on the HTTP layer, there is no JavaScript
| engine. If your modal open a form that will trigger some kind
| of XHR, you'll "simulate" the HTTP traquets that the form modal
| could have done. Hurl is not a kind of Playwright for instance.
| gabesullice wrote:
| 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!
| kaan_keskin wrote:
| this looks nice. is it possible to set a variable after a request
| and use it later in another request?
| mhio wrote:
| Yeah... [Captures] csrf_token: xpath
| "normalize-space(//meta[@name='_csrf_token']/@content)"
|
| The use the name with mustaches
| {{csrf_token}}
|
| - https://hurl.dev/docs/capturing-response.html
| genericspammer wrote:
| Can you have different environments or profiles or whatever, with
| different global variables?
| DownGoat wrote:
| Yes you can use env files, and then use the template syntax in
| the request files.
| https://hurl.dev/docs/templates.html#injecting-variables
| 1a527dd5 wrote:
| 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.
| johns wrote:
| I also hated that Runscope changes weren't version controlled
| :) We had started work on that but then things went sideways.
| 1a527dd5 wrote:
| Oh wow, of course I would run into the founder of Runscope on
| here.
|
| Loved Runscope it served it's purpose until something came
| along that that offered the same + version control.
| QuiCasseRien wrote:
| interesting tool !
|
| premiere fois que je vois qqch de cool sortir d'orange.
| jicea wrote:
| Ah ah ah thanks for this! There are a lot of Open Source
| projects from Orange => https://github.com/Orange-OpenSource
| lelanthran wrote:
| 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.
| molszanski wrote:
| I am using it and I love it :)
| a57721 wrote:
| In the JVM projects, I use Karate for integration tests:
| https://github.com/karatelabs/karate
|
| It gives you full control of constructing requests and assertions
| because test scenarios may include arbitrary JavaScript.
| globular-toast wrote:
| 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?
| mdtrooper wrote:
| I love this kind of tools (easy, simple and cli). I remember that
| https://httpie.io/cli or https://jqlang.org/ .
| kalli wrote:
| This looks interesting. Longtime user of the Vscode-restclient,
| but have been moving over to httpyac lately for the scripting and
| cli use. Will take a look to see if hurl is a good fit.
|
| One annoying thing I've found in testing these tools is that a
| standard hasn't emerged for using the results of one request as
| input for another in the syntax of `.http` files. These three
| tools for instance have three different ways of doing it:
|
| * hurl uses `[Captures]`
|
| * Vscode-restclient does it by referencing request names in a
| variable declaration (like: `@token =
| {{loginAPI.response.body.token}}`).
|
| * While httpyac uses `@ref` syntax.
|
| From a quick round of testing it seems like using the syntax for
| one might break the other tools.
|
| [1]: https://hurl.dev/docs/capturing-response.html
|
| [2]: https://github.com/Huachao/vscode-restclient
|
| [3]: https://httpyac.github.io/guide/metaData.html#ref-and-
| forcer...
| jicea wrote:
| Guilty to have created yet-another-format for HTTP client! To
| "mitigate" this issue, you can use `hurlfmt` (distributed along
| `hurl`) that would allow you to export a Hurl file to JSON. You
| could then go from this JSON to another... It's not magic but
| it can help if you're going to change from Hurl to another
| thing.
| kalli wrote:
| No worries, it's also interesting to see different peoples
| approaches to the best syntax for this. Exporters/importers
| do make life a bit easier I suppose.
|
| I don't know what the mechanism/incentive for getting a
| standard would be either. Probably most likely would be if
| there was one clear "winner" that everyone else felt the need
| mirror.
|
| In any case, appreciate the reply and the tool. Good luck
| with it.
| jiggawatts wrote:
| What's really special is that Visual Studio Code and Visual
| Studio both have .HTTP files... which are incompatible with
| each other.
|
| Conway's Law in action, ladies and gentlemen.
| lambda-science wrote:
| Isn't that very similar to Jetbrains HTTP Client ?
| epalm wrote:
| 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()"?
| blueflow wrote:
| 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.
| hliyan wrote:
| I must say, the sample section[1] does an excellent job of making
| a case for the tool, especially to people who are inclined to
| make a snap judgement about the usefulness of the tool within the
| first 5 minutes (I'm sometimes guilty of this).
|
| [1] https://github.com/Orange-OpenSource/hurl?tab=readme-ov-
| file...
| yoavm wrote:
| 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.
| jicea wrote:
| A simple GET with a status code is just GET
| http://foo.com HTTP 200
|
| You could write also GET http://foo.com
| HTTP * [Asserts] status == 200
|
| HTTP serves as a marker of the response section
| jorgeleo wrote:
| So we are not doing telnet anymore?
| WhitneyLand wrote:
| 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>"
| perrygeo wrote:
| Hurl is awesome. A while back I ported a small web service from
| Python to Rust. Having rigorous tests of the public API is
| amazing; a language-independent integration test! I was able to
| swap it out with no changes to the public API or website.
|
| Worth mentioning that using Hurl in Rust specifically gives you a
| nice bonus feature: integration with cargo test tooling. Since
| Hurl is written in Rust, you can hook into hurl-the-library and
| reuse your .hurl files directly in your test suite. Demo:
| https://github.com/perrygeo/axum-hurl-test
| twodave wrote:
| I took a lot of inspiration from this project when designing my
| own HTTP testing tool[0]. We needed to be able to run hundreds of
| tests quickly, and in parallel. If that is something you need and
| you like Hurl, then you might like Nap also.
|
| [0] https://naprun.dev
| bitpush wrote:
| Is the config same/different/similar than hurl? Do you have a
| page that outlines the differences, if any?
| twodave wrote:
| The main difference is that nap works off of YAML. You can
| get an idea of how it works by clicking on "The Basics"[0] on
| the left-hand side of the page.
|
| [0] https://naprun.dev/the-basics/
| Thaxll wrote:
| It looks interesting, I had a look a the dependencies, 1.5k lines
| for a cli tool to test http calls ( and more ), is it the norm in
| Rust?
|
| https://github.com/Orange-OpenSource/hurl/blob/master/Cargo....
| ewpratten wrote:
| You should probably be looking at the Cargo.toml file(s) (for
| direct dependencies at least) instead of the lock file as the
| lock file will include dependencies used for dev/testing.
| ninetyninenine wrote:
| 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?
| dm03514 wrote:
| 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 :)
| jicea wrote:
| Maintainer here, thanks for the feedbacks. 6-7 years ago, when
| we started working on Hurl, we started with a JSON then a YAML
| file format. We gradually convinced ourself to write a new file
| format and I completely understand that it might feel weird. We
| tried (maybe not succeeded!) to have something simple for the
| simple case...
|
| I'm really interested by issues with the documentation: it can
| always be improved and any issues is welcome!
| renegat0x0 wrote:
| I created something different yet similar.
|
| You make GET request to server with any of supported crawlers and
| obtain result in JSON
|
| https://github.com/rumca-js/crawler-buddy/
|
| Supports request, selenium, Httpx, curl cffi, etc
| zackify wrote:
| Oh wow! This reminds me so much of what I was trying to do almost
| 10 years ago but I was too much of a noob to make it make more
| sense haha.
|
| https://github.com/zackify/legible
| cyri wrote:
| Nice. This looks way better than this one written in Go:
| https://github.com/vdobler/ht it uses hjson.
|
| We used it very often a couple of years ago. Will try hurl.
| jcmfernandes wrote:
| It's nice, and there's an emacs mode for it:
| https://github.com/JasZhe/hurl-mode
| wiradikusuma wrote:
| IntelliJ has had this "plain text HTTP" feature for a while. I'm
| wondering if it is backed by Hurl?
| manithree wrote:
| With nice editor integration (especially emacs), hurl is a good
| postman replacement.
|
| Kinda niche, but I wrapped libhurl to make it really easy to make
| an AWS Lambda availability monitor out of a hurl file
| https://gitlab.com/manithree/hurl_lambda
| infogulch wrote:
| Hurl has been great for testing in my RAD templating web server
| project. Like dm03514 says itt, 'The hurl-based tests really help
| to enforce the "client" perspective.' It's packaged for 3
| application environments including a docker image (x2 archs, x3
| oses) and with Hurl its easy to ensure the tests pass at the
| client level in all three environments.
|
| It would be nice to have fancy-regex; today I tried to write a
| regex to match a case like this ~ <link
| href="/assets/reset.css\\\?hash=(.*)" integrity="\\\1"
| rel="stylesheet"> ~ but the regex crate (and thus hurl asserts)
| can't do backreferences so I guess I'll just live without
| checking that these two substrings match.
|
| I wish there was some way to test streamed updates / SSE.
| Basically, open a connection and wait, then run some other http
| requests, then assert the accumulated stream from the original
| connection. https://github.com/Orange-
| OpenSource/hurl/discussions/2636
| 3eb7988a1663 wrote:
| 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.
| sorashi wrote:
| It's just an alternative to Postman and similar so you don't
| have to start a whole damn electron window just to test a few
| http requests. It's somewhere between a curl script and
| Postman, so it hits the right spot for many.
| jicea wrote:
| We used Hurl to go from a ktor web server to a spring boot
| rewrite (Java/Kotlin stack). It was a breeze to have a kind of
| specifications test suite independent of the server stack and
| helped us a lot in the transition.
|
| Another benefit is we built a Docker image for production and
| wanted to have something light and not tight to the
| implementation for integration tests.
| thiht wrote:
| > 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.
|
| I don't use hurl but I've used other tools to write language
| agnostic API tests (and I'm currently working on a new one) so
| here's what I like about these kinds of tests:
|
| - they're blind to the implementation, and that's actually a
| pro in my opinion. It makes sure you don't rely on internals,
| you just get the input and the output
|
| - they can easily serve as documentation because they're
| language agnostic and relatively easy to share. They're great
| for sharing between teams in addition to or instead of an
| OpenAPI spec
|
| - they actually test a contract, and can be reused in case of a
| migration. I've worked on a huge migration of a public API from
| Perl to Go and we wanted to keep relatively the same contracts
| (since the API was public). So we wrote tests for the existing
| Perl API as a non-regression harness, and could keep the exact
| same tests for the Go API since they were independent from the
| language. Keeping the same tests gave us greater confidence
| than if we had to rewrite tests and it was easy to add more
| during the double-run/A-B test period
|
| - as a developer, writing these forces you to switch context
| and become a consumer of the API you just wrote, I've found it
| easier to write good quality tests with this method
| johns wrote:
| Shout out to the OG Hurl HTTP tool
| https://web.archive.org/web/20100112040154/http://hurl.it/
| kqr wrote:
| > 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.
| deepsun wrote:
| I believe it's built-in to IntelliJ, just create a file with
| .https extension.
___________________________________________________________________
(page generated 2025-06-20 23:01 UTC)