Meetup with Brian Marick

Marktplaats, Amsterdam / 20-03-2010

Brian Marick zal op zijn tour langs Europese congressen op zaterdag 20 maart Nederland aan doen. Op deze dag organiseert Devnology in samenwerking met AgileHolland een meetup.

Brian is een van de auteurs van het beroemde Agile Manifesto en heeft verschillende boeken geschreven, waaronder Programming Cocoa with Ruby, Everyday scripting with Ruby en The Craft of Software Testing.

Voor deze bijeenkomst zal Brian een presentatie geven over Mocking:

I think I finally understand Mocks

To my lasting embarrassment, I reviewed the very first paper on mock objects, "Endo-Testing: Unit Testing with Mock Objects" (Mackinnon, Freeman, Craig), and completely missed the point. Like many people since, I mistook mocks for stubs. That confusion was quickly cleared up–and yet, as I came to hear more about what’s sometimes called the “London School” of test-driven design, particularly as represented by Nat Pryce and Steve Freeman, I remained puzzled by the consequences of mocking. Representatives of the school described it as placing the emphasis on defining the interactions between objects, rather than on defining classes. It was easy to accept that intellectually, but I didn’t understand what it meant for program design or the act of programming.
 
Now I do, I think, and I think I’ve hit upon an interestingly odd way to explain it:
 
1. In the early days, what we now call test-driven design (TDD) was known as test-first programming. The name changed after practitioners realized how to create tests that (a) ran fast and (b) didn’t break wholesale when the underlying code changed. They did it by building programs that had properties we knew all along were important: high cohesion and low coupling. But until TDD, the short-term cost of those properties kept us from enjoying their long-term benefits. TDD made them–and good design in general–matter to us right now because we care about ease of work. So we did what we should have done all along.
 
2. Mocks make programming even easier, especially when programming is done in “sashimi” or “tracer bullet” style, where classes are changed or modified in the order that user input would encounter them.
 
3. More importantly, programmers using mocks have more control over the pacing or cadence of their work. Working with mocks leads to a steadier pace than ordinary TDD.
 
4. The desire to control pace produces designs even more uncoupled and cohesive. In the talk, I’ll explain my claims in more detail, by using the audience as "objects" while I act out the addition of a feature to a web application I’m writing in Ruby and Objective-J.

Agenda

16:00 - 17:00
Presentatie van Brian Marick
17:00 - 17:30
Discussie
18:00
Aansluitend diner in nabijgelegen restaurant


Deelnemers worden van harte uitgenodigd mee te gaan eten, dit is dan wel voor eigen rekening.

Deze bijeenkomst wordt georganiseerd door Devnology en AgileHolland

&


Register for this event

This event is not open for registration
Qwan 5dff39510bacfcefb54e89f953eddfc1a7a21185b7128d96ff6b466f56acb6d9
Macaw 06e9331a5321067b592bf45ea39db7df6792dc976000d24d3ee4043d99203514
Finalist e304343cdbeb0996cc1e7a26527993a5fa2db87ca53a81fb15dca22a35d7f28c

Devnology is a non-profit organisation and thus depends on sponsors. Thanks to our wonderful sponsors all Devnology events are free!