TDD Workshop

gistfile1.txt

Day 1
“Everyone
 believes their way is the right way. Everyone is wrong.”

Best
 Practices v. Patterns


XP
 Values

Courage


Simplicity


Feedback


Communication


Respect

What
 does your team do to support these values? Violate these values?

TDD
 Workshop

Concisely
 Describe TDD and Tests


RPS
 Kata in Java



call
 the shot!


watch
 out for untested logic



Why
 TDD? (GO FAST FOREVER, etc.)


Qualities
 of Good Test Suites



FAST


CLEAN


CONFIDENCE


FREEDOM
 TO REFACTOR



XP
 Principles Introduced during the day:
Assume
 Simplicity


DIP
 Workshop


Separate
 Concerns (avoid big ball of mud)


Definitions
 of DIP



source
 code deps oppose runtime flow of control


HLP
 independent of LLD


depend
 in the direction of stability



History
 of DIP


Paper
 Coding (smart home; Bulb, Switch)



UML
 at class level


UML
 at JAR level



Refactoring
 Oven9K / Temp Regulator Algo


Smart
 Home TDD Kata






Resources



TDD

Parker’s
 writings on TDD:



What
 is a Unit Test? (The Answer Might Surprise You).
 (Or watch this
 little talk. Or this
longer
 talk.)


Why
 TDD? (or Watch
this
 video starting at 5m30s)


The
 Test Double Rule Of Thumb


The
 Four Goals of a Good Test Suite




More:



Check
 out the original book, "Test
 Driven Development By Example",
 by Kent Beck


More
 on Test Doubles: Read The
 Little Mocker, and chapter 11 “Using
 Test Doubles” in "xUnit
 Test Patterns"


Katas
 (Read "The
 Coding Dojo" and/or peruse
http://kata-log.rocks/)


Refactoring
 (Read the Code Smells chapter in Fowler’s Refactoring
 book; practice all the refactorings in that book, leveraging an IDE’s automated refactoring support as much as possible - preferably a Jetbrains IDE.
Also, read about the Composed Method
 and Method Object refactorings in Kent Beck's book
Implementation Patterns.)


Working
 with a legacy codebase? Read Working
 effectively with legacy code and
The
 Mikado Method




Dependency
 Inversion



History
 (read "The
 Clean Coder" - Chapter 10, Estimation)


Definitions
 (Read "Agile
 Software Development – Principles, Patterns, and Practices"
 Chapter 11 "The Dependency Inversion Principle")


Test
 Doubles Definitions (read Martin
 Fowler on Mocks)


Or
 simply study “polymorphism”—dependency inversion is simply looking at the implications polymorphic dispatch has for your dependencies

---


Bad Code
---

- Opaque
- Rigid
- Fragile
- Viscous
- Immobile

---

S O L I D

Dependency Inversion
---

- Decoupling code
- Source code dependencies oppose the runtime flow of control
- high level policies *don't* depend on low level details
-

Runtime Dependency
---

- Still in the same direction

Source Code(Compile time) Dependency
---

- Independent compile time dependency


Sample code

problems:
1. Oven could be injected. instantiated forever (heap overflow)
2. infinite loop
3. Variable, method names
4. hex values
5. interface for Oven

---

Test Doubles
---

5 types

- Dummy (readonly): Doesn't do anything. When dependency is needed but don't care about the output.
Used when double is needed but should not be used

- Stub (write): Test double that implements something and returns a value.

- Spy (write): Was this method called?. i.e. calledWith(..), called(5).times()

- Mock(write): Spies with verify method.
`expect(mock.verify())`

- Fake (read/write): real behavior of the interface.