You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since delegate_to uses expect under the hood, it is not easy to develop a fully comprehensive test suite for it (aka write a dedicated spec for every single edge case).
(Failed expect raises Exception descendants, not StandardError, and then RSpec uses them for internal control flow, so you can not catch them by yourself, otherwise, you'll brake RSpec)
Current implementation uses a lot of if statements that check for used chainings. It will immediately become a maintenance burden when someone decides to introduce a new chain.
(Dynamic Composition looks like the best option for the next version of delegate_to)
Utilize bundle exec rspec <spec_file> --format=documentation to check whether Spec descriptions should work as almost end-user documentation is satisfied.
allow(object).to receive(method) do can be used instead of and_wrap_original.
original = object.send(:method, method) to get original method.
refactorRefactoring was the initial reason of the PR. From Conventional Commits.
1 participant
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Since
delegate_to
uses and_wrap_original under the hood it can NOT be combined with otherallow
stubs.(They override each other depending on the order, see
stub_service
does NOT mock in combination withdelegate_to
#22)Since
delegate_to
usesexpect
under the hood, it is not easy to develop a fully comprehensive test suite for it (aka write a dedicated spec for every single edge case).(Failed
expect
raisesException
descendants, notStandardError
, and then RSpec uses them for internal control flow, so you can not catch them by yourself, otherwise, you'll brake RSpec)Current implementation uses a lot of
if
statements that check for used chainings. It will immediately become a maintenance burden when someone decides to introduce a new chain.(Dynamic Composition looks like the best option for the next version of
delegate_to
)Complexity: Hard (+ a lot of routine work to do)
Hard Requirements:
expect
in the new implementation.delegate_to
. Return onlytrue
orfalse
frommatches?
. Let RSpec handle the rest for you.delegate_to
feature will be Receive Counts support. It should immediately benefit from the Open/Closed principle.Soft Requirements:
delate_to
is a Facade.matches?
is a Builder.Open Questions:
delegate_to
?Notes:
Current implementation (0.2.0) of
delegate_to
can be foundCurrent implementation (0.2.0) of
delegate_to
specs.Utilize
bundle exec rspec <spec_file> --format=documentation
to check whetherSpec descriptions should work as almost end-user documentation
is satisfied.allow(object).to receive(method) do
can be used instead ofand_wrap_original
.original = object.send(:method, method)
to get original method.Beta Was this translation helpful? Give feedback.
All reactions