Skip to content

Fixes issue 915 - displaying invalid counts instead of irrelevant arguments

Created by: johnceh

Why?

Fix for issue #915 (closed) - Confusing failure message when other arguments involved with received messages. Invalid counts more relevant in situations where multiple arguments in play.

What Changed?

Previously, an exception was raised immediately after a received message did not match one of items in the argument list. Now the standard invalid count message is returned unless there is no match in the entire list. Tests by @myronmarston copied from #841 added in.

What Else Changed?

(updated 04/03/2015 with code refactor, adding in suggestions from @myronmarston and @JonRowe)

  • Took out new method and rolled it into existing raise_unexpected_message_args_error method
  • DRY'd up some error methods by adding common code to message_error (name to generic?)
  • Rolled up received_arg_list into format_received_args and setup to handle single/multiple messages with single/multiple arguments.
  • Removed a few splat operators so a more standardized messages list can be sent for single and multiple messages.

(updated 04/05/2015)

  • Added fix for 2nd part of ticket. Display errors fixed for expect to receive messages.
  • A couple of different options on this one, so took the path of least resistance. Added similar_messages to SimpleMessageExpectation should allow the removal of (defined?) check. Adding check for similar_messages.blank? is not necessary, but would reduce redundant calls to unadvise method. Open to suggestions if not matching existing patterns.

(updated 04/08/2015)

  • Added no-op to SimpleMessageExpectation (This removed the previous complexity warning I was getting earlier, so I removed the rubocop disable I had to add in earlier)
  • Using existing format_args instead of using new method
  • Making distinctions between args and args_with_mulitple_calls for clarity.

Merge request reports