Thank you for your response! :D

In the meantime I also found an old (2015) discussion on the Rspec google 
groups about virtually the same topic: 
https://groups.google.com/forum/#!msg/rspec/XgY5wHI-S_c/whRRWbwDBwAJ

The main issue that was mentioned there is that running all examples of a 
property test inside `it` (using the technique of e.g. your example 
pseudo-code) 
means that before/after(:each) hooks are only executed once for the entire 
run, rather than once per generated input value-set.

I will probably end up using the approach proposed by you for now for 
simplicity's sake, 
but if there exists a way that allows users to leverage the existing test 
lifecycle hooks that RSpec provides, that would of course be much nicer :-).

Sincerely,

~W-M/Qqwy
On Sunday, June 23, 2019 at 2:58:08 PM UTC+2, Jon Rowe wrote:
>
> Hi
>
> The easiest way to do this will be to consider your “keyword” as a DSL 
> that creates examples. Then within the examples you create handle the logic 
> of running the block provided to perform the work you want. You will need 
> to swallow the errors yourself if you don’t want RSpec to perform them. 
> This is very much pseudo code but might help point you in the right 
> direction...
>
> module PropertyTesting
>   module_function
>
>   def test_properties(properties, &block)
>
>     # for simplicity use the existing DSL to create examples
>     it “tests the properties” do
>       begin
>         properties.each do |property|
>           block.call(property)
>         end
>       # its up to you what you rescue here, either all errors or just 
> ExpectationNotMet
>       rescue
>         shrink
>       ensure
>         # You can create either a new ExpectationNotMet error with 
> whatever you want
>         # or you can use standard ruby errors, or you could create an 
> AggregateFailures 
>         # error with the original and/or the new error, or any other 
> errors. Up to you.
>         raise a_final_rspec_error if errors
>       end
>     end
>   end
> end
>
> Let me know if I can help further 
>
> Cheers
> Jon Rowe
> ---------------------------
> [email protected] <javascript:>
> jonrowe.co.uk
>
> On 20 June 2019 at 15:34, Wiebe-Marten Wijnja wrote:
>
> Greetings, dear Rspec developers and users!
>
> I am currently in the process of writing a Property Testing 
> ('QuickCheck'-like) library, because while there exist a couple of gems 
> that allow this,
> they are either (a) very feature-incomplete and do not properly support 
> shrinking, and/or (b) unmaintained for a very long time.
>
> The basics of the library work, but I want to be able to integrate it with 
> Rspec.
> Essentially, this means that I want to introduce an alternate keyword 
> instead of 'it', (named 'forall') which would call the block passed to it 
> many times (a thousand by default) with different values of increasing 
> complexity.
> As soon as one call/set of inputs  is found to cause a failure, the 
> library will then *shrink* this set of inputs to be the simplest set of 
> inputs that still causes a failure.
> The current implementation of this works, but it assumes that all failures 
> will be raised as exceptions, and that failures will not be captured/logged 
> by some reporting mechanism in-between.
>
> w.r.t. Rspec this means that I have the following questions:
>
> 1. How can I/should I wrap the test execution context?
> 3. Most importantly, I want to report the initial failure that happens 
> (with the set of inputs at that time), as well as the failure that happens 
> on the simplest shrunken set of inputs. 
>     I do not want Rspec to report on the fifty failures that happened 
> while shrinking.
>
>
> Thank you,
>
> ~Qqwy/ W-M 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"rspec" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/2e8b4357-2fcd-45b0-b7d1-63dd2413e1d8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to