Tag Archives: mockito

JavaOne – Mockito 2 Cleaner Tests and Enhanced Productivity

Posted on by
Reply

“Mockito 2 Cleaner Tests and Enhanced Productivity”

Speaker: Szczepan Faber
[nice twitter handle – @mockitoguy]

For more blog posts from JavaOne, see the table of contents

Stats

  • Started in 2008 to overcome shortcomings of JMock and EasyMock
  • Mockito is number 3 Java library on github [not sure what this means]
  • 2016 – Mockito 2 came out
  • About 50 unique contributors

Conceptual

  • Talked about the importance of clean code
  • Plugged GTD (gettng things done) book
  • A good test tell you why it fails without using debugger
  • Used given/when/then format in tests – recommends actually writing those three words in comments; encourages to think about test that way
  • PowerMock extends/integrates with Mockito so can test legacy code

Live coding based on https://github.com/szczepiq/mockito-conferences-2017/tree/javaone

General

  • Fails with clear messages
  • Can click on line in console output message to go to it in IDE
  • JMock/EasyMock use strict mocking as default. Mockito is lenient by default so don’t have to put “unnecessary” code in the tests. [he did a demo of strict mocking simulation. I didn’t follow it. the code is here]
  • MockitoJUnit.rule().strictness(Strictness.STRICT_STUBS) can change default. MockitoSession is the non-rule way to do so. Strict stubbing good as finds unused code. [confused; he just got through saying that strict mocking is bad. but it’s good for stubbing?].
  • Mockito 3 has strict stubs this as a default.
  • With strict stubs, don’t need to call verify – finds unused coe
  • There’s a way to enroll in strict stubs without the @Rule [didn’t show how]
  • Use shipkit for CD

My take: CodeRanch is in the process of migrating to Mockito (from a mix of Mockito/JMock and random other things). It was good to see best practices. I’m going to miss strict mocking. Trying to keep an open mind. I was able to follow most of it with my minimal experience with Mockito. Thought there’d have been a bit of intro up front. I left with questions though. For example, I don’t follow why strict mocks are bad but strict stubs are good. Which is conceptual so I was hoping to follow his point. And he has another session immediately after this one so can’t ask hallway questions.

upgrading mockito – forwards and backwards

Posted on by
Reply

I upgraded Mockito from 1.X to 2.X. (Because I wanted to try out the JUnit 5 MockitoExtension.

JUnit 4

I like @RunWith(MockitoJUnitRunner.class). The two main benefits:

  • Inject mocks as instance variables instead of static call to MockitoAnnotations.initMocks(this);
  • Tells you about unnecessary mock setup calls you have.

JUnit 5

Instead of the Mockito Runner, you use @ExtendWith(MockitoExtension.class). This was written by the JUnit 5 team. The two main benefits:

  • Inject mocks as instance variables
  • Inject mocks as method parameters

What’s missing

In JUnit 5, Mockito no longer tells you about extra setup code that you should delete. And neither version automatically calls verify() like JMock does. I miss that feature and wish Mockito had it. It is nice to be able to have the mock library tell you the actual code didn’t call an expected value without having to remember to code a call to verify the mock. (If Mockito does have it and I didn’t notice, please leave a comment!)