Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hurl 4.0.0

hurl.dev

Post reply on HN
Print view View original

51–60 of 104 posts

Re: Hurl 4.0.0

#51

Post by EdwardDiego »

bityard wrote: post #28

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 seri…

I never realised how much the emojis in my terminal annoyed me, until you mentioned this didn't have them, and I got excited.

Re: Hurl 4.0.0

#52

Post by dijit »

convalescindrey wrote: post #50
dijit wrote: post #49

Earlier quoted context omitted.

The bigger problem here is that you have devs, devs make bugs. if you don't have devs there are no bugs, problem solved.

If devs have to do QA themselves, many issues magically disappear.

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.

Re: Hurl 4.0.0

#53

Post by convalescindrey »

wanderingstan wrote: post #24
krat0sprakhar wrote: post #2

> Hurl is a command line tool powered by curl, that runs HTTP requests defined in a simple plain text format: 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

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

Re: Hurl 4.0.0

#54

Post by debarshri »

sedatk wrote: post #48
debarshri wrote: post #19

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 aroun…

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)

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.

Re: Hurl 4.0.0

#55

Post by convalescindrey »

jicea wrote: post #22
smarkov wrote: post #10

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 c…

Hi maintainer here! Thanks a lot for the kind words!

Great project!

A comment I'd have is that it's quite hard to find out who authored this fine piece of software.

Re: Hurl 4.0.0

#56

Post by jicea »

convalescindrey wrote: post #53
wanderingstan wrote: post #24

Earlier quoted context omitted.

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. (I…

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

Re: Hurl 4.0.0

#57

Post by convalescindrey »

dijit wrote: post #52
convalescindrey wrote: post #50

Earlier quoted context omitted.

If devs have to do QA themselves, many issues magically disappear.

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…

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.

Re: Hurl 4.0.0

#58

Post by jug6ernaut »

kbenson wrote: post #37
smarkov wrote: post #10

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 c…

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…

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.

Re: Hurl 4.0.0

#59

Post by klysm »

debarshri wrote: post #54
sedatk wrote: post #48

Earlier quoted context omitted.

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)

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.

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

Re: Hurl 4.0.0

#60

Post by klysm »

rrgok wrote: post #45

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…

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
Post reply on HN