Sign in or
Mocking with Java Night
Event PitchA 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.
- Steven and Nat's talk notes and slides are available here.
- Felix's notes to follow
Steve FreemanSteve 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.
Nat PryceNat 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 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.
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.
For more information on coding dojos see the Coding Dojo Wiki.
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.
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
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.
Latest page update: made by rrees
, Jun 1 2008, 10:49 AM EDT
(about this update
About This Update
Edited by rrees
284 words added
19 words deleted
- complete history)
Keyword tags: None
More Info: links to this page
|Started By||Thread Subject||Replies||Last Post|
|rrees||Thanks for coming||0||May 29 2008, 4:18 AM EDT by rrees|
Thread started: May 29 2008, 4:18 AM EDT Watch
Had a good night last night, really interesting to hear the discussion. Loads of thanks to our great speakers and to everyone who attended the evening from Paul and myself.
Details on the Dojo exercises and retrospective will be added to this page later this week.
|MarisO||I want to attend this meeting||9||May 21 2008, 10:13 PM EDT by saramic|
Showing 2 of 2 threads for this page