Fable Tales comments

Results 18 comments of


                                            Fable Tales

do..end for procs where you don't use return value, {} when you do

I think it's better to differentiate what a block is for using the two different ways of declaring.

do..end for procs where you don't use return value, {} when you do

do end and {} bind differently if you leave out parenthases. Example: ``` class ExpectationTarget attr_reader :matcher, :target def initialize(target) @target = target end def to(matcher, &blk) p '------ in...

Take a stronger stance on nil

I guess it depends. Is this limited only to objective style, or causing good design to fall out of style guidelines?

the def keyword is quite good.

pretty sure you're terrible

the def keyword is quite good.

objective reason: minimizes meta programming.

An exception is raised when invoking an `any_instance` expectation on a subclass that has an `any_instance` stub on its parent class

Thanks for the clear issue @joshuap! I'm convinced this is a bug, but I don't have the time to work out the root cause right now. Hopefully more info soon.

An exception is raised when invoking an `any_instance` expectation on a subclass that has an `any_instance` stub on its parent class

OK, my repro isn't quite right

An exception is raised when invoking an `any_instance` expectation on a subclass that has an `any_instance` stub on its parent class

1a7e923 is the actual commit which reproduces this issue. I am really struggling with git today. Sorry everyone.

Spies create false positives when used with dynamic matchers

> We could fix this with an additional check in the dynamic matcher, checking it's not a spy. 👍

Negative message expectations interact weirdly with failure aggregation

Thoughts (in no particular order) > We could odd an option to RSpec::Mocks.verify that allows the caller to control if eager failures are re-raised or not. Then rspec-core could pick...