Event Pitch

A lot of people think that mocking is easy, they have usually embedded it into the way they think and the way they code. A lot of people think that mocking is hard, particularly on existing codebases, what should they mock, where and what value does mocking really bring to developers?

Good mocking means touching on a lot of important topics in development. Some are fundamental object orientated design theories like encapsulation and decoupling. Some are hot new buzzwords like behaviour-driven development. Mocking supports many well-established Agile practices such as refactoring.

One thing that advocates of mocking are united in is that code that is mockable is code whose behaviour will be easier to verify and verifiable code is more reliable code and reliable code is better code.

Speakers

• Nat Pryce and Steve Freeman on Mocking and JMock
• Felix Leipold on Mockito

Talk Notes

• Steven and Nat's talk notes and slides are available here.
• Felix's notes to follow

Speaker's Biographies

Steve Freeman

Steve is a pioneer of Agile software development in the UK, he has built applications for banks, ISPs, financial data providers, and specialist software companies. He has trained and coached teams in Europe , America, and Asia. Previously, he worked in research labs, software houses, earned a PhD, and wrote shrink-wrap software. Steve also taught in the Computer Science department at University College London. He is a presenter and organizer at international industry conferences, and was conference chair for the first London XpDay.

Steve was an author of the original Mock Objects paper and is a committer on jMock and Hamcrest.

www.m3p.co.uk/blog
www.mockobjects.com

Nat Pryce

Nat Pryce provides consultancy and training in software design and
development process and practices, mostly in the finance and telecoms
industries. He is also a part-time research fellow at Imperial College
where he studies mobile, context aware systems.

He frequently presents at international conferences. He helped
establish the XP Day family of conferences and was programme chair of
XP Day London in 2005 and 2006.

He is a developer of jMock and Hamcrest, which has now been integrated
into JUnit. He has also released a number of other open source
libraries and tools to support agile and test-driven development.

He (occasionally) blogs at http://nat.truemesh.com.

Felix Leipold

Felix Leipold is a programmer, who currently works as a Consultant for ThoughtWorks UK. He has worked in several projects using agile methods and TDD. Before joining ThoughtWorks in 2006 he worked for SAP in Germany, where he was involved in application and tools development.

Currently he is thinking a lot about "how to get testing right", especially on large scale projects. He was lucky enough to be around, when Szczepan Faber came up with his Mockito mocking library, an attempt to make mocking and stubbing more simple. Mockito embodies some of the lessons learnt from working in large development teams.

Mockito Home Page

Feedback on the evening

• Mockito talk could have had better examples
• The room was too hot, the airconditioning could have been better.

Dojo

The dojo example was a fake servlet in the style of Struts 1 Action where the validate method needs to have some behaviour refactored. The test cases define the behaviour the validation method should have. Steve and Nat pointed out that a better way of approaching the problem, if you encounter it in the wild, is to write an end to end functional test that checks the top-level behaviour and then refactor that rather than creating a chain of mock objects and then refactoring that.

Dojo Links

For more information on coding dojos see the Coding Dojo Wiki.

Dojo Code

The code from the dojo is in the attachment below. This is a copy of the Eclipse project from the evening in exactly the state it was in when we finished the dojo. This includes my attempts to solve the problem in both JMock and Mockito.

Dojo Retrospective

What we learned

• The Code Dojo format (x2)
• Mocking is a design tool
• JMock & Mockito
• Eclipse shortcuts
• Example for real-life legacy code
• Mock objects are cool

What stopped us from learning

• No handouts of presentations
• Too little time for the dojo
• Bad example for showing different framework usage
• Start with green tests
• Encourage TDD next time
• Less complex test next time
• Initial toy example
• Group was too big
• Start with a design (domain) problem
• Show how mocking influences design
• Hard to see from the back
• It's all a bit secret, current pair should share their thoughts louder
• Allow more discussion when pairs are working
• Bigger projector (x2)

Actions from the Dojo

Since not all of these comments will apply to our next Dojo on Ajax and Javascript not all have an immediate action. However one clear thing I am taking away on the issue of mocking is that people wanted to see how TDD and mocking fit together to design new code rather than scaffold legacy code. This might fit well with a discussion of BDD and DDD so it might be possible to put something together.

The projector is the biggest we have but I believe we might be able to move it back further after the initial talk to make the screen clearer.

I think we can facilitate better to work around the size of the group and the discussion issues. However we'll clearly need to review the issue if it turns up in later retrospectives.

It may be an idea to add a "warm up" phase to the dojo in case you have never seen the frameworks before. An idea arising from other dojo exercises is to do a safety check first to see how we should begin the dojo.