New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New strict mocking API - MockitoSession #857

Closed
mockitoguy opened this Issue Dec 30, 2016 · 4 comments

Comments

Projects
None yet
2 participants
@mockitoguy
Member

mockitoguy commented Dec 30, 2016

Background

  • Mockito strictness (improved debuggability, cleaner tests) is described in a blog post and in issue #769
  • Strict stubbing is already supported with JUnit rules - #807
  • Open PR for supporting strict stubbing with JUnit Runners - #854
  • This ticket intends to discuss the goals and implementation of strict stubbing without JUnit Rules / Runner

Initial design

public class SampleTest {   
    @Mock IMethods mock;
    
    //Initialize mocks similar to MockitoAnnotations.initMocks(this), also configures strictness
    MockitoSession mockito = Mockito.mockitoSession().initMocks(this).strictness(Strictness.STRICT_STUBS).startMocking();

    @After public void after() {
        //After the test has completed, we detect unused stubs and validate mockito usage
        mockito.finishMocking();
    }

    //start and finish mocking invocations can be hidden in a common test base class
    //or abstracted out in unit test framework specific way (custom rule, etc.)

    @Test public void some_test() {
        //...
    }
}    

Alternative new public API methods

(no longer considered since the feature is merged)

//1
MockitoMocking mockito = Mockito.startMocking(this, Strictness.STRICT_STUBS);
mockito.finishMocking();
//2
MockitoSession mockito = Mockito.mockitoSession().initMocks(this).strictness(Strictness.STRICT_STUBS).startMocking();
mockito.finishMocking();
//3
MockitoSession mockito = MockitoSessionBuilder.mockitoSession().testClassInstance(this).strictness(Strictness.STRICT_STUBS).start();
mockito.stop();

Discussion

  • other ideas to meet the goal (better debuggability / cleaner tests without JUnit)
  • good naming / API for the feature
  • consistency with existing support for strictness with Runner and the Rule

We would love to hear your feedback!

@bric3

This comment has been minimized.

Show comment
Hide comment
@bric3

bric3 Jan 15, 2017

Contributor

Here's my opinion :

  • Regarding alternative 1/2/3, I prefer the API with an actual variable. Using static methods requires a hidden thread local state, while it's ok for stubbing, I think this could be bad design choice for the mockiting session. Also without MockitoSession variable it's hard to interact with, and always requires some static method.
  • Not in favor of option 1, as it kinda dismiss the builder style API. And it's probably harder to evolve such API in a non breaking way.
  • Not in favor of option 3, regarding the testClassInstance as it does not explain what it does with the test class instance. While initMocks suggests the behavior behind this.
  • I don't mind having the static factory method on either MockitoSession or Mockito, both are good. A Mockito start point would probably be more discoverable though and will get along other lifecycle Mockito methods, like reset, validateUsage, etc... While MockitoSession could be an opportunity to have a more focused API.
Contributor

bric3 commented Jan 15, 2017

Here's my opinion :

  • Regarding alternative 1/2/3, I prefer the API with an actual variable. Using static methods requires a hidden thread local state, while it's ok for stubbing, I think this could be bad design choice for the mockiting session. Also without MockitoSession variable it's hard to interact with, and always requires some static method.
  • Not in favor of option 1, as it kinda dismiss the builder style API. And it's probably harder to evolve such API in a non breaking way.
  • Not in favor of option 3, regarding the testClassInstance as it does not explain what it does with the test class instance. While initMocks suggests the behavior behind this.
  • I don't mind having the static factory method on either MockitoSession or Mockito, both are good. A Mockito start point would probably be more discoverable though and will get along other lifecycle Mockito methods, like reset, validateUsage, etc... While MockitoSession could be an opportunity to have a more focused API.
@mockitoguy

This comment has been minimized.

Show comment
Hide comment
@mockitoguy

mockitoguy Jan 16, 2017

Member

@bric3, great feedback!!!

I summarized my POV in (#865 (comment)).

Regarding alternative 1/2/3, I prefer the API with an actual variable.

All options are using variable, I removed it for clarity (but it became less clear :) I will update the ticket.

I don't mind having the static factory method on either MockitoSession or Mockito, both are good. A Mockito start point would probably be more discoverable though and will get along other lifecycle Mockito methods, like reset, validateUsage, etc... While MockitoSession could be an opportunity to have a more focused API.

Yes. Both approaches have pros and cons. Let's go ahead with Mockito.mockitoSession() at this time.

Member

mockitoguy commented Jan 16, 2017

@bric3, great feedback!!!

I summarized my POV in (#865 (comment)).

Regarding alternative 1/2/3, I prefer the API with an actual variable.

All options are using variable, I removed it for clarity (but it became less clear :) I will update the ticket.

I don't mind having the static factory method on either MockitoSession or Mockito, both are good. A Mockito start point would probably be more discoverable though and will get along other lifecycle Mockito methods, like reset, validateUsage, etc... While MockitoSession could be an opportunity to have a more focused API.

Yes. Both approaches have pros and cons. Let's go ahead with Mockito.mockitoSession() at this time.

mockitoguy added a commit that referenced this issue Jan 16, 2017

New MockitoSession public API
- Changed the public API to MockitoSession per our discussion at #857.
- MockitoSession offers meaningful name and semantics as opposed to somewhat cryptic MockitoMocking interface
- New builder style interface for constructing session instances

Pending

- lots of javadoc (TODOs in code)
- coverage for builder edge cases (e.g. when someone does not provide strictness or init mocks, etc.)

@mockitoguy mockitoguy changed the title from Strictness without JUnit to Strictness without JUnit - New MockitoSession API Jan 17, 2017

@bric3

This comment has been minimized.

Show comment
Hide comment
@bric3

bric3 Jan 18, 2017

Contributor

All options are using variable, I removed it for clarity (but it became less clear :) I will update the ticket.

ok

Yes. Both approaches have pros and cons. Let's go ahead with Mockito.mockitoSession() at this time.

That's fine by me :)

Contributor

bric3 commented Jan 18, 2017

All options are using variable, I removed it for clarity (but it became less clear :) I will update the ticket.

ok

Yes. Both approaches have pros and cons. Let's go ahead with Mockito.mockitoSession() at this time.

That's fine by me :)

mockitoguy added a commit that referenced this issue Jan 21, 2017

New MockitoSession public API
- Changed the public API to MockitoSession per our discussion at #857.
- MockitoSession offers meaningful name and semantics as opposed to somewhat cryptic MockitoMocking interface
- New builder style interface for constructing session instances

Pending

- lots of javadoc (TODOs in code)
- coverage for builder edge cases (e.g. when someone does not provide strictness or init mocks, etc.)

mockitoguy added a commit that referenced this issue Jan 24, 2017

New MockitoSession public API
- Changed the public API to MockitoSession per our discussion at #857.
- MockitoSession offers meaningful name and semantics as opposed to somewhat cryptic MockitoMocking interface
- New builder style interface for constructing session instances

Pending

- lots of javadoc (TODOs in code)
- coverage for builder edge cases (e.g. when someone does not provide strictness or init mocks, etc.)

mockitoguy added a commit that referenced this issue Jan 29, 2017

New MockitoSession public API
- Changed the public API to MockitoSession per our discussion at #857.
- MockitoSession offers meaningful name and semantics as opposed to somewhat cryptic MockitoMocking interface
- New builder style interface for constructing session instances

Pending

- lots of javadoc (TODOs in code)
- coverage for builder edge cases (e.g. when someone does not provide strictness or init mocks, etc.)
@mockitoguy

This comment has been minimized.

Show comment
Hide comment
@mockitoguy

mockitoguy Jan 29, 2017

Member

Closed via #865

Member

mockitoguy commented Jan 29, 2017

Closed via #865

@mockitoguy mockitoguy closed this Jan 29, 2017

@mockitoguy mockitoguy changed the title from Strictness without JUnit - New MockitoSession API to New strict mocking API - MockitoSession Jan 29, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment