This repository has been archived by the owner on Aug 24, 2023. It is now read-only.
Allows mocks to inherit public methods from other objects #2
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hey!
So, this is one that I find super useful but completely understand if you're not a fan. Usually in larger projects, a mocked interface might have multiple public methods that get called in a feature test. You're only interested in testing one of those methods, but still need to provide a fallback for the other methods.
You might think "that's a partial mock", but I beg to differ because the partial mock might still be doing too much and may still require you to mock the methods/dependencies out.
This PR adds the idea of inheriting public class methods for a mock. You pass it a class, and it will look up its public methods and defer to those if no hard expectation has been set.
Example
First of all, we create an object. It doesn't have to implement anything, but it can if we want to force it to have all of the methods of the interface we're testing.
Now we write our test. We can call methods without using
expect
, and it will use the method call from the inherited class instead.However, if we use an
extend
call, it will opt for our overridden version:This gets even more powerful in feature tests, where other methods on the interface might be being called, but you're not interested in testing them at this moment.
This implementation also allows you to provide multiple inherited classes, so you could mix and match methods together based on the use case required for the given test.
Let me know what you think. Hope you're having a good week!