`ish` assertion in Assert??

[kellyredding]

http://spin.atomicobject.com/2012/11/13/convenient-trick-for-tolerance-based-test-assertions-using-ish/?utm_source=rubyweekly&utm_medium=email

Something to consider?

[jcredding]

I've ran into this once with testing time or floats, don't remember exactly, but yeah it was really annoying to deal with. Having some kind of ish would be convenient.

[kellyredding]

@jcredding bringing this back up. How would you think this would look? What would the assert statement look like?

[jcredding]

@kellyredding - Well it seems like you have a possible 3 values for this: expected, tolerance and actual. Tolerance can be optional, but you will probably want to be able to override it. This means the assertion either takes 3 values or you have to build a special kind of object. This can also already be done with a regular assert:

assert [*min..max].include?(actual)

So I'd assume you'd need to somehow make it more convenient than this.

# three args
assert_in_delta expected, actual, delta
assert_close expected, actual, delta

# if you wanted to force building some kinda object
assert_in_delta Assert::Tolerance.new(expected, delta), actual
# you could provide a convenient method if desired
assert_close tolerance(expected, delta), actual

Not sure what the best style is. assert_in_delta is verbose, but makes sense. assert_close or assert_is_close_to might be less robotic. If you wanted to use ish then assert_equalish might be the way to go. I'm not sure how you can consistently apply the tolerance without requiring that they support + and -. This should obviously work for numbers and I think for dates, which are the 2 primary uses for this kinda assertion.

[kellyredding]

@jcredding you make a good point in that it should be simpler than [*min..max].include?(actual). I think that's simple enough already.

I think we should close and shelve this for now - you OK with that?

[jcredding]

@kellyredding - I'm good with closing this.