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

Show HN: PBT – A property-based testing library for Ruby

github.com

Post reply on HN
Print view View original

11–20 of 37 posts

Re: Show HN: PBT – A property-based testing library for Ruby

#11

Post by mikepurvis »

Alifatisk wrote: post #8
jack_riminton wrote: post #6

Interesting! I wonder how this could be applied to a Rails project (since that's what ruby is most used for). For example how would it know to test a wide selection of possible values for different variables if they're not explicitly set up?

> Rails [...] that's what ruby is most used for I wish that wasn't the case, I use Ruby heavily for gluing different systems together.

Outside of language level preferences, is there something about the ecosystem around Ruby that makes it particularly well suited to this? I would have thought Python was the glue language winner just because there are already bindings to the entire universe available for it.

Re: Show HN: PBT – A property-based testing library for Ruby

#12

Post by [deleted] »

mikepurvis wrote: post #11
Alifatisk wrote: post #8

Earlier quoted context omitted.

> Rails [...] that's what ruby is most used for I wish that wasn't the case, I use Ruby heavily for gluing different systems together.

Outside of language level preferences, is there something about the ecosystem around Ruby that makes it particularly well suited to this? I would have thought Python was the glue language winner just because there are already bindings to the entire universe available for it.

[deleted]

Re: Show HN: PBT – A property-based testing library for Ruby

#13

Post by portpecos »

mikepurvis wrote: post #11
Alifatisk wrote: post #8

Earlier quoted context omitted.

> Rails [...] that's what ruby is most used for I wish that wasn't the case, I use Ruby heavily for gluing different systems together.

Outside of language level preferences, is there something about the ecosystem around Ruby that makes it particularly well suited to this? I would have thought Python was the glue language winner just because there are already bindings to the entire universe available for it.

Ruby just simply isn’t the glue language winner because of the heavy emphasis on rails.

From a systems perspective, I had to switch to python because it has pyroute2, which supports rtnl, devlink, ethtool and more.

I would have thought ruby had a full-fledged netlink library right now considering the stability of chef and puppet.

But all I could find was this from 8 years ago: https://github.com/BytemarkHosting/netlinkrb

I started off with ruby for systems glue but now I have a mix of python and ruby. I wish it was all ruby but the lack of updated “glue gems” and the prevalence of updated “glue eggs” means python really is the “glue language winner”.

Re: Show HN: PBT – A property-based testing library for Ruby

#14

Post by tybug »

parentheses wrote: post #10

Very specific question: when tests fail due to a single example, you suggest creating a specific assertion with the given seed. I imagine the seed is used to generate data and depending on the order of your generators, it produces different results. For example, in: PBT.assert(seed = ..) do PBT.property(PBT.integer, PBT.string) ... end Would changing the order of parameters to `property` change the actual test case?

(not OP but I would be surprised if the answer wasn't) yes, because you're changing the order in which the random draws are interpreted. But this isn't a problem in practice because you generally aren't changing the generator in the middle of debugging a failure.

Re: Show HN: PBT – A property-based testing library for Ruby

#16

Post by Alifatisk »

mikepurvis wrote: post #11
Alifatisk wrote: post #8

Earlier quoted context omitted.

> Rails [...] that's what ruby is most used for I wish that wasn't the case, I use Ruby heavily for gluing different systems together.

Outside of language level preferences, is there something about the ecosystem around Ruby that makes it particularly well suited to this? I would have thought Python was the glue language winner just because there are already bindings to the entire universe available for it.

Ruby is my choice primarily because of its syntax and the powerful meta-programming capabilities. The ecosystem in itself is not any richer or better than Python, no, Python has faaar superior libraries and vibrant support. In my case, I've found ruby-toolbox.com to be useful when I need to scavenge for libraries.

Re: Show HN: PBT – A property-based testing library for Ruby

#17

Post by Alifatisk »

portpecos wrote: post #13
mikepurvis wrote: post #11

Earlier quoted context omitted.

Outside of language level preferences, is there something about the ecosystem around Ruby that makes it particularly well suited to this? I would have thought Python was the glue language winner just because there are already bindings to the entire universe available for it.

Ruby just simply isn’t the glue language winner because of the heavy emphasis on rails. From a systems perspective, I had to switch to python because it has pyroute2, which supports rtnl, devlink, ethtool and more. I would have thought ruby had a full-fledged netlink library right now considering the stability of chef and puppet. But all I could find was this from 8 years ago: https://github.com/BytemarkHosting/netli…

> all I could find was this from 8 years ago: https://github.com/BytemarkHosting/netlinkrb

Yeah, that's so typical. I've almost become used to this, seeing useful gems being very old. To me, I see that as either abandoned (which means I have to fork it and polish it) or the gem is considered complete.

Re: Show HN: PBT – A property-based testing library for Ruby

#18

Post by sam2426679 »

portpecos wrote: post #13
mikepurvis wrote: post #11

Earlier quoted context omitted.

Outside of language level preferences, is there something about the ecosystem around Ruby that makes it particularly well suited to this? I would have thought Python was the glue language winner just because there are already bindings to the entire universe available for it.

Ruby just simply isn’t the glue language winner because of the heavy emphasis on rails. From a systems perspective, I had to switch to python because it has pyroute2, which supports rtnl, devlink, ethtool and more. I would have thought ruby had a full-fledged netlink library right now considering the stability of chef and puppet. But all I could find was this from 8 years ago: https://github.com/BytemarkHosting/netli…

> I wish it was all ruby

Why do you not wish it was all Python?

Re: Show HN: PBT – A property-based testing library for Ruby

#19

Post by parentheses »

tybug wrote: post #14
parentheses wrote: post #10

Very specific question: when tests fail due to a single example, you suggest creating a specific assertion with the given seed. I imagine the seed is used to generate data and depending on the order of your generators, it produces different results. For example, in: PBT.assert(seed = ..) do PBT.property(PBT.integer, PBT.string) ... end Would changing the order of parameters to `property` change the actual test case?

(not OP but I would be surprised if the answer wasn't) yes, because you're changing the order in which the random draws are interpreted. But this isn't a problem in practice because you generally aren't changing the generator in the middle of debugging a failure.

So, this means refactoring becomes potentially difficult. While the gem is still a great accomplishment and very useful, I'd have to engineer my way around this issue before using it with things like a Rails Model which could have changing shape.

@OP:

I wonder if the README (and possibly runner) should suggest writing a test-case that doesn't rely on PBT when the user wants to preserve a case for future testing.

The issue here is that if you're saving a singular example and it represents a weird corner case, it's totally conceivable that a small change will result in an invisible change to that test case.

Another idea: it'd be great if the test could simply take examples that are failing and add them to a `failing_examples.rb` or some such. I know I'd use a feature like this quite a bit.

Re: Show HN: PBT – A property-based testing library for Ruby

#20

Post by [deleted] »

parentheses wrote: post #19
tybug wrote: post #14

Earlier quoted context omitted.

(not OP but I would be surprised if the answer wasn't) yes, because you're changing the order in which the random draws are interpreted. But this isn't a problem in practice because you generally aren't changing the generator in the middle of debugging a failure.

So, this means refactoring becomes potentially difficult. While the gem is still a great accomplishment and very useful, I'd have to engineer my way around this issue before using it with things like a Rails Model which could have changing shape. @OP: I wonder if the README (and possibly runner) should suggest writing a test-case that doesn't rely on PBT when the user wants to preserve a case for future testing. The…

[deleted]
Post reply on HN