Thank you for your reply! I would like to do both: Create an alias that under the hood registers new tests at runtime. The current implementation does the former (the alias) successfully, based on the tips you and others gave earlier in this thread :-).
I am still looking for how to register new tests while the system is running. This is the reason why: Running all tests for a single property within a single 'it' essentially clusters e.g. 1000 tests into a single one. This poses a problem for tools that notify users on 'slow tests' and similar metrics, because these metrics won't be meaningful anymore. On Thursday, July 16, 2020 at 9:31:47 PM UTC+2, Jon Rowe wrote: > > So it is possible, but difficult, to register new tests within an RSpec > suite during a run. > > However I’m not sure thats what you want, and its not what I was > suggesting. > > I was suggesting that a `prop_check` alias, or similar, creates one test, > but that within that test it runs its block multiple times for each > property. > > Something along the lines of: > > def self.prop_check(string, &block) > it(string) do > generate_properties.each(&block) > end > end > > Which is pseudo code, but you can see if you had a property generator that > kept running the “test block”until it satisfied conditions, or failed once, > you could achieve what you want. > > RSpec supports wrapping exceptions into one (it powers our aggregate > failures functionality) so you could have one test representing multiple > values like this easily enough. > > Cheers > Jon Rowe > --------------------------- > [email protected] <javascript:> > jonrowe.co.uk > > On 16 July 2020 at 13:51, Wiebe-Marten Wijnja wrote: > > Thank you for your 'late' reply... allow me to reply even later (10 months > after your reply ^_^'). > > One problem I encountered, is that RSpec seems to require that examples > are *first* created, and only *then* they are all run. Is this true? > For property-testing it makes sense to run the tests for a particular > property only until the first failure occurs (and at that time we'd want to > shrink the input back to the most basic input that creates the same error). > Is this approach fundamentally incompatible with RSpec's architecture, or > is there some way to do this? ('this' being to define more tests on the > fly.) > > ~Marten/Qqwy > > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/rspec/f4ff4acb-ab79-46ea-b55c-a3b03daf7d34o%40googlegroups.com.
