Difference between revisions of "Mastering Acceptance TDD to Unit TDD with Legacy or New Code: Workshop"

Line 2: Line 2:
 
<br>
 
<br>
 
== Environment & Preparation ==
 
== Environment & Preparation ==
ACTION >> read and answer the questions in here, ASAP:
+
ACTION >> read and order supplies and answer the questions in here, ASAP:
 
[[Workshop Environment - SBE ATDD UTDD with mob-programming]]
 
[[Workshop Environment - SBE ATDD UTDD with mob-programming]]
 
<br>
 
<br>

Revision as of 14:04, 2 December 2018



Environment & Preparation

ACTION >> read and order supplies and answer the questions in here, ASAP: Workshop Environment - SBE ATDD UTDD with mob-programming

Overview

10 days


TDD is powerful and practical. But it is not quickly or easily adopted because it is a profoundly new behavior for developers. And that in addition to a new set of design and code skills.


Since 1998, having in-depth coached many hundreds of developers, have come to the conclusion that (1) it takes at least 10 days full time of coaching, and (2) on your production code (not toy exercise code), to create a sticky behavior change in which developers both want to apply Acceptance TDD (ATDD, AKA Behavior-Driven Development or BDD) and Unit TDD (UTDD), and can effectively do it.


ATDD and UTDD are the practice of always implementing executable specifications code (sometimes un-insightfully called tests) before the solution code. In addition to the obvious benefits that (1) executable specifications actually get written and executed for most code with thorough coverage and (2) the practice and mindset of "building quality in" rather than "inspect/test defects out"), a more subtle but important benefit is that (3) when we start by thinking very concretely—with code—in the role of a calling client to the new code before it is written, it (4) clarifies our design, (5) tends to create better designs with lower coupling, higher cohesion, and flexible dependency injection, (6) and becomes a more fun and creative way to combine writing tests with code. Hence, TDD is far more than "just executable specs" — it is a kind of creative micro-design step that drives better design.


In this workshop you will learn how to think in and apply TDD, and establish it as a consistent behavior for your development team, in the context of your existing code.


Also, the original concepts of ATDD/BDD has evolved into the larger and more mature concept and practice of Specification by Example (SbE), to create executable customer specifications. So the workshop will start with the practice of SbE.


TDD quickly leads developers to see the need for and value of reducing coupling in their code, and for techniques to break dependencies so that executable specs can be run quickly in isolation. Thus, a critical adjunct skill in TDD is learning how to create and inject alternate test doubles (fakes, stubs, ...). In this workshop you will learn how to create stubs, fakes, mocks, object factories/mothers, how to break dependencies, and how to apply dependency injection methods.


Learning how to break dependencies for testing in isolation is especially important in the context of legacy code; in this workshop you will to work with your legacy code to break dependencies, “bring it under test”, introduce flexible configuration in your code, and apply TDD.


Refactoring is a disciplined design skill to improve the structure of code without changing its external behavior. And refactoring is the key part of the TDD cycle. Thus, in this workshop you will learn the various “code smells” and the refactorings to clean them up and create clean code. Refactoring is aided on automated refactoring tools built into popular IDEs; thus in this course you will learn to apply an automated refactoring tool, in addition to manual refactoring.


Methods of Education

Having coached hundreds since the 1990s in mastering TDD, have empirically discovered a relatively high-impact method: 10 days in a workshop room with 1 group of 8 developers, working in a coding dojo style with mob programming, while I (the coach) guide the group second-by-second in every aspect of creating code, with continual feedback and discussion.


Audience & Participants

  • developers, architects, technical leaders
  • 8 max
  • The 8 people must be from a max of 2 different stable teams (e.g. 4 from each team). Why? TDD is a team-based very new and different behavior and the majority of a team needs to go through the learning together so that the team changes behavior. I have discovered that the min required number of participants out of an average team size of 7-ish developers, is 4 developers. 8 people all from only 1 team is best, and recommended if this workshop will be repeated with many teams; but OTOH if this is a one-time workshop, then people from 2 teams increases the spread of the learning.
  • NB: for the first 3 hours of DAY 1, we will also need the participation from one or two subject experts on the requirement will be implementing, so that we can do Specification by Example with the team and the experts who can clarify all requirement questions.

Prerequisites

  • skill in programming
  • knowledge of your legacy code


Objectives

Upon completion of this workshop, participants should be able to:

  • apply SbE
  • apply ATDD
  • apply UTDD
  • break dependencies in your legacy code and create “test doubles” (fakes, mocks, stubs, ...)
  • inject dependencies with flexible techniques
  • write "clean code"
  • identify code smells
  • apply refactorings
  • use a suitable ATDD framework and an xUnit framework
  • understand the use and misuse of mock objects
  • bring legacy code “under automated test”