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

 
(15 intermediate revisions by the same user not shown)
Line 1: Line 1:
<br>
 
<br>
 
 
<br>
 
<br>
 
<br>
 
<br>
 
== Environment & Preparation ==
 
== Environment & Preparation ==
 +
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>
 
<br>
 
<br>
 
== Overview ==
 
== Overview ==
4-5 days.
+
10 days
  
This is a combination of a 2-3 day course with structured learning exercises, FOLLOWED BY a 2-3 day "clinic" or workshop applying the skills to your existing legacy code. (For a total of 4-5 days; the exact timing is content dependent on the knowledge of the developers, the state of the legacy code, and the legacy problems to tackle).
 
  
 +
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.
  
This information-packed and hands-on course shows developers and technical leaders how to apply test-driven development (TDD) and refactoring in the context of your legacy code.
 
  
 +
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.
  
TDD is powerful and practical. It’s the practice of always writing test code before the code to be tested, in small micro-test-and-develop cycles. In addition to the obvious benefits that (1) tests actually get written and executed for most code with thorough test coverage and (2) the practice and mindset of "building quality in" by test-FIRST rather than test-LAST (which tries to "inspect old 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 testing" — it is a kind of creative micro-design step that drives better design.
 
  
 +
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 course 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. You’ll learn and work with a popular free open-source TDD frameworks.
 
  
 +
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.
  
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 tests 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 course you will learn how to create stubs, fakes, mocks, object factories/mothers, how to break dependencies, and how to  apply  dependency injection methods.
 
  
 +
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.
  
Learning how to break dependencies for testing in isolation is especially important in the context of legacy code; in this course you will to work with your legacy code to break dependencies, “bring it under test”, introduce flexible configuration in your code, and apply TDD.
 
  
 +
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.
  
Refactoring is a disciplined design skill to improve the structure of code without changing its external behavior. And refactoring is part of the TDD cycle. Thus, in this course you will learn the various “code smells” and the refactorings to clean them up. Refactoring is aided on automated refactoring tools built into popular IDEs or editors, such as the Eclipse or Visual Studio; thus in this course you will learn to apply an automated refactoring tool, in addition to manual refactoring.
 
  
 +
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.
  
STEP ONE - Course (2-3 days): You will learn to apply all these skills in the context of an exercise, applying TDD and refactoring.
 
  
 +
'''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.
  
STEP TWO - Clinic/Workshop (2-3 days): Now, onwards to the messy reality of your existing legacy code. The teacher/coach will start by demonstrating how to work with your legacy code, to break dependencies and apply TDD and refactoring, in a "coding dojo" style workshop. This is followed by small groups of the developers (for example, 2 people together), working in parallel on different sections of their legacy code to break dependencies, bring it "under test", and start to apply TDD and refactoring to it. During this phase, the coach will rotate across all the groups, giving guidance and feedback. There will also be some periods of "show and tell", looking at the existing solutions the smaller groups are creating with your legacy code.
 
  
 +
== 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.
  
== Methods of Education ==
 
Discussion, presentation, Q&A, workshop exercises
 
  
 +
== Audience & Participants ==
 +
* developers, architects, technical leaders
  
== Audience ==
+
* 8 max
Developers, architects, test engineers, technical leaders.
 
  
 +
* 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.
  
== Level==
+
* 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.
Intermediate: This course introduces concepts and techniques that the attendee will apply during the workshop.
 
  
  
 
== Prerequisites ==
 
== Prerequisites ==
skill in programming; knowledge of your legacy code
+
* skill in programming
 +
 
 +
* knowledge of your legacy code
  
  
 
== Objectives ==
 
== Objectives ==
Upon completion of this course, students should be able to:
+
Upon completion of this workshop, participants should be able to:
* apply TDD
+
* apply SbE
 +
* apply ATDD
 +
* apply UTDD
 
* break dependencies in your legacy code and create “test doubles” (fakes, mocks, stubs, ...)
 
* break dependencies in your legacy code and create “test doubles” (fakes, mocks, stubs, ...)
 
* inject dependencies with flexible techniques
 
* inject dependencies with flexible techniques
* separate test set up code into clear, reusable elements
 
 
* write "clean code"
 
* write "clean code"
 
* identify code smells
 
* identify code smells
 
* apply refactorings
 
* apply refactorings
* use a suitable xUnit frameworks
+
* use a suitable ATDD framework and an xUnit framework
 
* understand the use and misuse of mock objects
 
* understand the use and misuse of mock objects
* bring legacy code “under test”
+
* bring legacy code “under automated test”
 
 
 
 
== Maximum Participants ==
 
16
 

Latest revision as of 14:17, 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”