hurl

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 o

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....

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...

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

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

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...

This looks great, would definitely use it for testing if websocket support ever gets added https://github.com/Orange-OpenSource/hurl/issues/1096

Hi, maintainer of Hurl [1] here. We're trying to write "simple" Rust as far as we can, without going into too much optimisation: very little lifetime usage, no async stuff (just classic multi-thread directly from the last sample of the Rust book), liberal usage of clone, no macros, reusing crates for C libcurl and libxml binding, limiting dependencies. We could certainly gain a lot of performances but with this first simple approach, the binary is already "fast"... The only advice I would give for someone going into Rust is to not try to optimise everything from the start to get a first "feeling" of the language. [1]: https://github.com/Orange-OpenSource/hurl

Looks to be similar to Hurl https://hurl.dev/ https://github.com/Orange-OpenSource/hurl Apache-2.0 Not sure, it's hard to parse your website. Too many empty taglines like "docs that do more" and "git-native", and the 5px font in your screenshots does not help. This screams "no programmers only designers here". Honestly it's a red flag for a programming tool.

I maintain a Rust project that is ~50,000 loc [1]. I've never felt that compiling is slow, in the contrary it's always a pleasure to see how fast the project compiles (at least in debug). In release, build time is longer but in this case, it's in the CI/CD so it doesn't bother me. We try to be very conservative with adding dependencies so it may help compilation time. Also I'm coming from a Java/Kotlin world so a lot of things appear like fresh air in comparison... [1]: https://github.com/Orange-OpenSource/hurl

Hurl https://github.com/Orange-OpenSource/hurl For those who prefer an efficient command line tool

Absolutely! I'm the maintainer of a small Open Source project [1] and this phrase makes me tickle. I totally get it that a maintainer doesn't want to merge some code, even if it's totally working. Is the new feature a niche case, or has if a wide audience? Is it aligned with the project goal/philosophy? Will it be easy to maintain/evolve/debug? Does it add unnecessary/unwanted dependencies? At the end of the day, the maintainer will be the person that have to work/support with this code. Please keep in mind that if you've spent an hour on a project, maintainers have have certainly spent hundreds if not thousands more time on it. [1]: https://github.com/Orange-OpenSource/hurl

> Surprisingly, the type wrapped by std::result::Result::Err doesn't need an Error bound: None of the errors types I create implements the trait Error. I'm just using simple enums with various variants and that's sufficient for me. The crates that I develop are mostly binary crate [1] so implementing the trait Error is maybe more prevalent in libraries crate. Reading the article, it feels a little overkill to me. I like the simple, straightforward approach (the one that you learn in the Book). I don't use anyhow also, I actively try to limit the dependencies I'm using. [1]: https://github.com/Orange-OpenSource/hurl