2. Plan-Do-Check-Act0 Originally called Plan-Do-Study-Act0
Created by Walter Shewhart at Bell Labs during the 1930s 3.
Iterative & Incremental Development0 The X-15 program in the
1950s used IID 4. Test-First in the Swinging 60s0 X-15 team members
seeded Project Mercury 0 Time-boxed half-day iterations 0 Tests
were written first 0 Reviews after each iteration 0 Top-down
development with stubs 5. We were doing incremental development as
early as 1957, in Los Angeles, underthe direction of Bernie
Dimsdale [at IBMs Service Bureau Corporation]. He wasa colleague of
John von Neumann, so perhaps he learned it there, or assumed itas
totally natural. I do remember Herb Jacobs (primarily, though we
all participated) developing a large simulation for Motorola, where
the technique used was, as far as I can tell, indistinguishable
from XP. When much of the same team was reassembled in Washington,
DC in 1958 todevelop Project Mercury, we had our own machine and
the new Share Operating System, whose symbolic modification and
assembly allowed us to build thesystem incrementally, which we did,
with great success. Project Mercury was the seed bed out of which
grew the IBM Federal SystemsDivision. Thus, that division started
with a history and tradition of incremental development. All of us,
as far as I can remember, thought waterfalling of a huge project
was rather stupid, or at least ignorant of the realities I think
what the waterfall description did for us was make us realize that
we were doing something else, something unnamed except for software
development. Gerald M. Weinberg 6. Waterfall in the 1970s &
80s0 Blame the DoD and the CMMI 7. Other stuff was happening0
Object-orientation 0 Simula from the late 60s 0 Smalltalk in the
70s at Xerox PARC0 Software distribution 8. Into the 1990s0 UML
evolves0 www arrives 9. What RUP was meant to be 10. What RUP
actually was 11. RAD elaboration in the 90s 12. XP arrives 13.
Test-Driven is in XP 14. Tests are Feedback in XP 15. Agile arrives
16. Agile is just XP, rebadged 17. and a Manifesto 18. The
Philosophy of TDD 19. The Testing Game0 Red: 0 Write a failing
test0 Green: 0 Pass the failing test0 Refactor 0 Clean the
implementation 20. Write a failing test0 To know what test to
write, you must: 0 Analyze your problem 0 Design your solution 0
Code intentionally0 To dislike Big Upfront Design is not to dislike
design 21. Agile Problem Analysis0 System Metaphor 0 Arises from
the Architectural Spike 0 A simple design with the defining quality
of explaining the system design without reference to documents0
User Experience 0 Arises from the set of all user stories 0
Provides a canvas onto which individual stories can be painted0
User Story 0 Describes a specific user expectation 0 Provides the
functional constraints of implementation 22. User Stories0 A user
story comprises one or more sentences in the everyday or business
language of the end user that captures what the user wants to
achieve 23. Agile Solutions0 Walk the solution: for each user story
0 Understand how this fits into the user experience 0 Understand
where the necessary functional implementation goes in the
architecture 0 Design the functional implementation 24. Goldilocks
Design0 Design only what you need0 avoid YAGNI (You Aint Gonna Need
It)0 Reuse existing implementation 0 be DRY (Dont Repeat Yourself)0
Prefer sketched designs over definitive design 0 allow TDD to be
part of your design process0 Dont experiment in code 0 use spikes
where necessary 25. First Exercise0 Brainstorm a realistic
candidate application0 Write a small set of user stories0 Elaborate
a user experience0 Articulate a system metaphor0 Time limit: one
hour 26. Analysis & Design0 There are a variety of approaches
to functionalanalysis and implementation design0 The most commonly
used are:0 The UML0 CRC Cards0 Design Patterns0 Linguistics &
Semantics0 Personas0 Storyboards 27. UML0 The UML (Unified Modeling
Language) 0 It has the advantage that many developers have at least
some familiarity 0 It has the disadvantage of significant
complexity 0 Most agile practitioners use sketch UML, typically on
a whiteboard, in order to convey a mental model of a proposed
solution 0 Be indicative, not definitive 28. UML Use Case Diagram0
Describes the functionality provided by a system in terms of actors
and their goals represented as use cases 29. UML Activity Diagram0
Used to describe the business and operational step-by-step
workflows of components in a system 30. UML Sequence Diagram0 Shows
how processes operate with one another and in what sequence 31. UML
Class Diagram0 Describes the structure of a system by showing the
systems classes, their attributes, methods, and the relationships
among the classes 32. CRC Cards0 Class Responsibility Collaboration
cards are abrainstorming tool, proposed by Ward Cunningham andKent
Beck0 They are typically used when determining which classesare
needed and how they will interact0 CRC cards are usually created
from index cards on whichare written:0 The class name0 Any base or
derived classes (if applicable)0 The responsibilities of the class0
The names of other classes with which the class willcollaborate to
fulfil its responsibilities 33. CRC Card 34. Design Patterns0 A
general reusable solution to a commonly occurringproblem within a
given context0 A design pattern is not a finished design that can
betransformed directly into code; it is a description ortemplate
for how to solve a problem that can be usedin many different
situations0 Typically show relationships and interactionsbetween
classes or objects, without specifying thefinal application classes
or objects that are involved 35. Some Creational Patterns0 Factory
method 0 Define an interface for creating an object, but let
derived classes decide which class to instantiate0 Lazy
initialization 0 Tactic of delaying the creation of an object, the
calculation of a value, or some other expensive process until the
first time it is needed0 Object pool 0 Avoid expensive acquisition
and release of resources by recycling objects that are no longer in
use0 Resource acquisition is initialization 0 Ensure that resources
are properly released by tying them to the lifespan of suitable
objects0 Singleton 0 Ensure a class has only one instance, and
provide a global point of access to it 36. Some Structural
Patterns0 Adapter 0 Convert the interface of a class into another
interface clients expect0 Bridge 0 Decouple an abstraction from its
implementation allowing the two to vary independently0 Facade 0
Provide a unified interface to a set of interfaces in a subsystem0
Proxy 0 Provide a surrogate or placeholder for another object to
control access to it 37. Some Behavioural Patterns0 Chain of
responsibility 0 Avoid coupling the sender of a request to its
receiver by giving more than one object a chance to handle the
request0 Command 0 Encapsulate a request as an object, thereby
letting you parameterize clients with different requests, queue or
log requests, and support undoable operations0 Iterator 0 Provide a
way to access the elements of an aggregate object sequentially
without exposing its underlying representation0 Null object 0 Avoid
null references by providing a default object 38. Linguistics &
Semantics0 Using the meanings andrelationships of words andphrases
employed in the userstories and other material toconstruct a
language map ofthe problem domain0 Especially useful whendealing
with expert systems 39. Personas0 Fictional characters created to
represent the different user types within a targeted demographic,
attitude and/or behaviour set that might use a site, brand or
product in a similar way 40. Storyboards0 A techniqueborrowedfrom
thefilmindustry0 Shows theuserexperiencein sequence 41. Second
Exercise0 Take one or more of the user stories from the
firstexercise and apply a selection of the analysis anddesign
techniques0 Draw up a list of the strengths and weaknesses of
thetechniques in relation to these particular user stories0 Time
limit: one hour 42. Testing Frameworks0 MSTest 0 Built-in to Visual
Studio0 Pex 0 Experimental white-box testing from MS Research0
NUnit 0 Early open source port of JUnit for .net0 MbUnit 0 Another
open source framework0 xUnit 0 Open source reset of NUnit0 SpecFlow
0 Open source behaviour-driven-development framework 43. Arrange,
Act, Assert0 The default pattern for unit tests 1. Arrange all
necessary preconditions and inputs 2. Act on the object or method
under test 3. Assert that the expected results have occurred 44.
Test naming conventions0 Ad-hoc 0 Anything goes0 Behavioural 0
Tests are named according to the behaviour under test 0 Good fit
for collaboration tests (distinct from unit tests) public void
customer_pays_in_cheque_to_current_account()0 Contractual 0 Names
follow the unit contract under test
http://alandean.blogspot.com/2011/11/unit-test-naming-convention.html
45. xUnit Assertions0 Fundamentals 0 Assert.True() or
Assert.False() 0 Assert.Null() or Assert.NotNull() 0 Assert.Equal()
or Assert.NotEqual() 0 Assert.Same() or Assert.NotSame()0
Exceptions 0 Assert.Throws() or Assert.DoesNotThrow()0 Type checks
0 Assert.IsType() or Assert.IsNotType() 0
Assert.IsAssignableFrom()0 IEnumerable 0 Assert.Empty() or
Assert.NotEmpty() 0 Assert.Single() 0 Assert.Contains() or
Assert.DoesNotContain() 0 Assert.InRange() or Assert.NotInRange()
46. System.Diagnostics.Debug0 Assertions 0 Debug.Assert() 0
Debug.Fail()0 Publication 0 Debug.Print() 0 Debug.Write() or
Debug.WriteIf() 0 Debug.WriteLine() or Debug.WriteLineIf() 47. TDD
at the Keyboard1. Add a new test2. Run all tests and see if the new
one fails3. Write some code4. Run all tests and see them succeed5.
Refactor code6. Repeat 48. Exercise 30 Create a solution with two
class libraries: 0 TicTacToe 0 TicTacToe.Facts0 Add a reference to
xUnit.net in the Facts library0 http://nuget.org/0 Use TDD to
implement Tic-Tac-Toe0
http://gojko.net/2009/08/02/tdd-as-if-you-meant-it-revisited/0 Time
limit: one hour 49. Refactoring Code0 A disciplined technique for
restructuring an existing body of code,altering its internal
structure without changing its external behaviour0 Usually
motivated by noticing a code smell0 There are two general
categories of benefits to the activity of refactoring 0
Maintainability0 It is easier to fix bugs because the source code
is easy to read and theintent of its author is easy to grasp0 This
might be achieved by reducing large monolithic routines into a set
ofindividually concise, well-named, single-purpose methods0 It
might be achieved by moving a method to a more appropriate class,
orby removing misleading comments. 0 Extensibility0 It is easier to
extend the capabilities of the application if it usesrecognizable
design patterns, and it provides some flexibility where nonebefore
may have existed 50. Refactoring Techniques0 Techniques that allow
for more abstraction 0 Encapsulate Field: force code to access the
field with getter and setter methods 0 Generalize Type: create more
general types to allow for more code sharing 0 Replace Conditional
with Polymorphism: move each leg of the conditional to an
overriding method in a derived class and make the original method
abstract0 Techniques for breaking code apart into more logical
pieces 0 Extract Method: turn part of a larger method into a new
method 0 Extract Class: moves part of the code from an existing
class into a new class0 Techniques for improving names and location
of code 0 Move Method or Field: move to a more appropriate class 0
Rename Method or Field: changing the name to one that better
reveals its purpose 0 Pull Up: move to a base class 0 Push Down:
move to a derived class0 Longer list 0
http://martinfowler.com/refactoring/catalog/index.html 51. Exercise
40 Create a solution with two class libraries: 0 RomanNumerals 0
RomanNumerals.Facts0 Use TDD to solve the problem0
https://sites.google.com/site/tddproblems/all-problems-1/Roman-number-conversion0
Refactor the code as you go0 Time limit: one hour 52. Test Doubles0
Objects that mimic real objects for testing purposes 0 Dummies 0
Have no behaviour or throw exceptions 0 Stubs 0 Provide the
behaviour of a real object 0 Spies 0 Record activity for later
verification 0 Mocks 0 Define the expected activity before the test
is run 0 Fakes 0 Employ a simpler implementation such as an
in-memory database0 See
alsohttp://martinfowler.com/articles/mocksArentStubs.html 53.
Mocking Frameworks0 Visual Studio doesnt have one built-in0 Moles0
Experimental framework from MS Research0 Open source 0 Moq,
NCrunch, NMock2, Rhino Mocks, fakeiteasy0 Commercial 0 TypeMock
Isolator, JustMock 54. SOLID Code0 Single Responsibility principle
0 An object should have only a single responsibility0 Open/Closed
principle 0 Objects should be open for extension, but closed for
modification0 Liskov Substitution principle 0 Objects should be
replaceable with instances of their derived types without altering
correctness0 Interface Segregation principle 0 Many client specific
interfaces are better than one general purpose interface0
Dependency Inversion principle 0 Depend upon abstractions; do not
depend upon concretions 55. Inversion of Control0 Microsoft 0 Unity
0 Common Service Locator0 Open source 0 Castle Windsor, Autofac,
StructureMap, Ninject, LinFu 56. Exercise 50 Create a solution with
two class libraries: 0 Translator 0 Translator.Facts0 Use TDD to
solve the problem0 TODO0 Refactor the code as you go0 Use test
doubles to isolate tests from dependenciesand resources to achieve
SOLID code0 Time limit: two hours
