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] 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/dejalu-217-6fa27999-d132-4ece-9c54-13b5b3bd2118%40jonrowe.co.uk. For more options, visit https://groups.google.com/d/optout.
