ACTION >> read and order supplies and answer the questions in here, ASAP:
Workshop Environment - SBE ATDD UTDD with mob-programming
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.
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.
Upon completion of this workshop, participants should be able to: