Sha256: f1f18a0fa5b6b53caa6a09552c765005a7ccb2d8333f567945e5fe26b100f1e7

Contents?: true

Size: 1.73 KB

Versions: 1

Compression:

Stored size: 1.73 KB

Contents

# 0.0.6

* Require pathname, which I missed because `bundle exec` loads it. Wups!

# 0.0.5

* Fix concurrency [#6](https://github.com/testdouble/mocktail/pull/6)

# 0.0.4

* Introduce Mocktail.explain(), which will return a message & reference object
  for any of:
  * A class that has been passed to Mocktail.replace()
  * An instance created by Mocktail.of() or of_next()
  * A nil value returned by an unsatisfied stubbing invocation
* Fix some minor printing issue with the improved NoMethodError released in
  0.0.3


# 0.0.3

* Implement method_missing on all mocked instance methods to print out useful
  information, like the target type, the attempted call, an example method
  definition that would match the call (for paint-by-numbers-like TDD), and
  did_you_mean gem integration of similar method names in case it was just a
  miss
* Cleans artificially-generated argument errors of gem-internal backtraces

# 0.0.2

* Drop Ruby 2.7 support. Unbeknownst to me (since I developed mocktail using
  ruby 3.0), the entire approach to using `define_method` with `*args` and
  `**kwargs` splats only further confuses the [arg
  splitting](https://www.ruby-lang.org/en/news/2019/12/12/separation-of-positional-and-keyword-arguments-in-ruby-3-0/)
  behavior in Ruby 2.x. So in the event that someone calls a method with an
  ambiguous hash-as-last arg (either in a mock demonstration or call), it will
  be functionally impossible to either (a) validate the args against the
  parameters or (b) compare two calls as being a match for one another. These
  problems could be overcome (by using `eval` instead of `define_method` for
  mocked methods and by expanding the call-matching logic dramatically), but
  who's got the time. Upgrade to 3.0!

# 0.0.1

Initial release

Version data entries

1 entries across 1 versions & 1 rubygems

Version Path
mocktail-0.0.6 CHANGELOG.md