Presented by Luca Minudel

Abstract:

In the last 16 months between 2009 and 2011 I’ve documented the experience of a team adopting the practice ofTDD with mock objects between 2007 and 2008. The software development team was part of a F1 Racing Team, was working with a large and complex code-base and was trained on the job using TDD with Mock Objects.

We observed that, in comparison with the code written before, the code written using TDD with Mock Objects was easier to understand, change and evolve, was more adherent to the S.O.L.I.D. design principles, and partially more adherent to the Law of Demeter.

As a result of these observations we were intrigued by the hypothesis that code developed with TDD using Mock Objects tends to conform to the S.O.L.I.D. principles and to the Law of Demeter as an emergent property, without an explicit policy to do so. This raised some interesting questions: does TDD with Mock Objects

• encourage good design ?
• promote good design and conformance to design principles ?
• in some degree lead to conformance to design principles even in the absence of an explicit policy to do so ?
• in some degree lead to learn and deeply understand and apply the design principle ?

In this session I will describe a verifiable hypothesis of the link between TDD and Mocks with SOLID and LoD, analyze the relation between practices and test smells defined by TDD with Mocks and removal of the design principles violations in specific lines of code, tell the experience of the team I observed and evaluate if it’s compatible with the initial hypothesis, discuss the results of qualitative experiments conducted since now and discuss the validity of what the team have learned for other teams, projects or contexts.

Here is the current draft of the paper this session is based on.

Format and length: 60 mins presentation

Some code will be shown and discussed to make it clear the topics presented.
There will be time to make questions, clarify point, and discuss the application of those finding in other teams/context.
Link to code will be given for who want to see in practice the ideas described.

Intended audience and prerequisites:

Everyone with some experience in unit testing and TDD and with interest into the relation between TDD and design. I.e. coders, TDD practitioners, coaches that teach TDD and design, Agile team members, academicians and researchers in the fields of Empirical software engineering and in Emergent Education.

Objective(s) of the session:

• describe the hypothesis of the link between TDD and Mocks with good design (specifically with SOLIDprinciples and LoD)
• describe the relation I’ve observed between practices and test smells defined by TDD with Mocks and removal of the design principles violations
• describe the effects on design of TDD with Mocks as observed, compare them with other TDDschools/styles and to explicit design activity
• invite attenders to try the exercises on-line and send code and questionnaire to me to collect data from other teams to validate the hypothesis

Benefits for participants and presenter(s):

Benefits for participants

• for coders: improve practical understanding of some design principles, move the focus from “what good design is” to “how to achieve it”
• for TDD practitioners: reflect upon and discus in depth about the relation between TDD and design, and about different valid schools/styles of TDD and their practices
• for coaches: get inspired on effective ways to teach TDD and design principles
• for team members: listen to what worked in another team and possibly find ideas that could be tried and applied in different teams/projects/contexts, reflect on how to use TDD with Mock to support the emergence of design in large code-base and in a decentralized way
• for tools designers: investigate the possibility to develop tool features that exploit emergent properties in the code
• for academicians and researchers in Empirical software engineering and in Emergent Education: the exploratory study documented in the paper and discussed in the session is useful to understand the phenomenon and to enable the development of a model and set up a rigorous plan for a comprehensive investigation. At that time no studies have been conducted in this area.

Benefits for the presenter(s):

• collect data from other teams to validate the hypothesis
• discuss the hypothesis with other teams and investigate the generalization of the findings to other teams and contexts and projects
• reflect and focus on key points of this experience, what has been learned and how this can be reused