search

paulbutcher / ScalaMock

Native Scala mocking framework
http://scalamock.org/
MIT License
502 stars 99 forks source link

trait org.scalamock.matchers.Matchers without protected incapsulation #364

Closed anatolysergeev closed 3 years ago

anatolysergeev commented 3 years ago

Hello, i don't understand why in trait org.scalamock.matchers.Matchers all methods encapsulate like protected. Can we reconsider encapsulation politics?

barkhorn commented 3 years ago

can you explain what problem or bug you are facing, or what additional usage you want to propose? Just reworking traits for political reasons doesn't sound worthwhile. Or, if this is a usage question, Matchers are explained here, please read: https://scalamock.org/user-guide/features/

anatolysergeev commented 3 years ago

I want more flexibility in writing my test. I want create all mocks in one place, not only under MockFactory trait. And i don't understand why this encapsulate politics have been chosen, may be u can explain me. And it's for me strange that Matchers has dependence in MockContext but not using it at all (mock, stub methods take implicit parametrs). I'm really straggling with this for my humble opinion unnecessary encapsulate politic. MockContext private too(((, but for spec2 it's not private.

barkhorn commented 3 years ago

The Matchers trait you refer to requires a MockContext to work. As you can see in the code, it creates FunctionAdapter instances for the various mock setup/expectation calls. These FunctionAdaptors then do some more work based on the arguments they were given to abstract from a concrete call into a more generic way of handling mock invocations.

As such, mixing in Matchers into your code separately doesn't give you an advantage. You will need to mix in MockFactory into your test suite.

What you describe in your last message - creating all mocks in one place - is also already possible by using a fixture. How that can be done is described in the user guide as well.

if that's what you want to do then you should probably create a common base class for all your tests that manages the fixture and then you can subclass and share your mocks throughout your code. We really don't need to change ScalaMock for that or cherry-pick which internal traits to mix in.