Rule compatible with old junit

[jerzykrlk]

• Mockito Rule based on MethodRule:
  • compatible with JUnit 4.7+, instead of 4.9+,
  • no need to initialize with new MockitoJUnitRule(this) - just new MockitoJUnitRule(),
• minor: ugly fix for building Gradle in Windows (Mockito won't build on a Windows machine #97),

[mockitoguy]

Thanks! Are those changes backwards compatible?

[jerzykrlk]

Not with the previous version of rule. The constructor has changed.
9 paź 2014 22:40 "Szczepan Faber" notifications@github.com napisał(a):

Thanks! Are those changes backwards compatible?

—
Reply to this email directly or view it on GitHub
#102 (comment).

[mockitoguy]

Oh I see.

We can only include backwards incompatible changes in major version changes
(we're more-less following http://semver.org/). I don't think we're ready
to do Mockito 2.0, yet :)

On Fri, Oct 10, 2014 at 6:26 AM, jerzykrlk notifications@github.com wrote:

Not with the previous version of rule. The constructor has changed.
9 paź 2014 22:40 "Szczepan Faber" notifications@github.com napisał(a):

Thanks! Are those changes backwards compatible?

—
Reply to this email directly or view it on GitHub
#102 (comment).

—
Reply to this email directly or view it on GitHub
#102 (comment).

Szczepan Faber
Core dev@gradle; Founder@mockito

[jerzykrlk]

Would adding a second dummy constructor, like @Deprecated MockitoJUnitRule(Object unusedTarget) count as backward compatibility? :)
Unfortunately, the implemented interface changed (TestRule -> MethodRule), too - what do you think?

[mockitoguy]

Would adding a second dummy constructor, like @Deprecated MockitoJUnitRule(Object unusedTarget) count as backward compatibility? :)

Yes :)

Unfortunately, the implemented interface changed (TestRule -> MethodRule), too - what do you think?

I'd say it's ok to change it. It's an incompatible change but feels OK.

It's interesting if we could have a method like: MockitoJUnit.rule() that
creates the rule and exposes only an interface.

On Fri, Oct 10, 2014 at 9:01 PM, jerzykrlk notifications@github.com wrote:

Would adding a second dummy constructor, like @deprecated
MockitoJUnitRule(Object unusedTarget) count as backward compatibility? :)
Unfortunately, the implemented interface changed (TestRule -> MethodRule),
too - what do you think?

Reply to this email directly or view it on GitHub
#102 (comment).

Szczepan Faber
Core dev@gradle; Founder@mockito

[jerzykrlk]

Here we go.
For now, MockitoJUnitRule.rule() returns MockitoJUnitRule. I took a look at org.junit.rules.ExpectedException first, just in case.

[mockitoguy]

This looks good, thanks!

API I'm thinking about is (does not have to be a part of this RB, just sharing the vision):

• We add new class "MockitoJUnit" that will contain all junit-integration stuff.
• New MockitoJUnit.rule() method that returns an interface in the signature (e.g. not a concrete class). This interface needs to inherit from JUnit hierarchy, for example MethodRule.
• deprecate entire MockitoJUnitRule class on the grounds of concrete class leaking to the api

@bric3, wdyt?

[jerzykrlk]

I think the conversation stopped for a while.

I can add MockitoJUnit.rule() soon, if we all agree.

After deprecating the entire MockitoJUnitRule class, would you create a new class to be returned from rule(), or still return MockitoJUnitRule?

[mockitoguy]

Don't worry, it's on my radar. Just been busy lately :)

On Tue, Oct 21, 2014 at 7:56 AM, jerzykrlk notifications@github.com wrote:

I think the conversation stopped for a while.

I can add MockitoJUnit.rule() soon, if we all agree.

After deprecating the entire MockitoJUnitRule class, would you create a
new class to be returned from rule(), or still return MockitoJUnitRule?

Reply to this email directly or view it on GitHub
#102 (comment).

Szczepan Faber
Core dev@gradle; Founder@mockito

[bric3]

• We add new class MockitoJUnit that will contain all junit-integration stuff.

At some point it could make sense. Note we still have not released the TestNG integration.

• New MockitoJUnit.rule() method that returns an interface in the signature (e.g. not a concrete class). This interface needs to inherit from JUnit hierarchy, for example MethodRule.

Agreed. For public API this is definitely recommended.

• deprecate entire MockitoJUnitRule class on the grounds of concrete class leaking to the api

OK

After deprecating the entire MockitoJUnitRule class, would you create a new class to be returned from rule(), or still return MockitoJUnitRule ?

That may not really matter as the API of rule exposes only an interface. Maybe MockitoJunitRule can be split in two, with the main code moved to internal, and the actual type would just extends the internal class (and still be deprecated)

[bric3]

Could you split this change in a separate commit. (Even in the same PR)

[jerzykrlk]

see here: #115

[mockitoguy]

Attempting merge...

[mockitoguy]

Merged!