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

&