Slide used for Ahmedabad Java Meetup on 25th Jan 2014

1. TDD Workshop
By Gopal Shah

2. Agenda
● Self Coding session – 45m
● Introduction to TDD – 15m
● TDD Group coding session – Part1 – 45m
● Break – 10m
● TDD Group coding session - Part2 – 45m
● TDD best practices & solution analysis – 30m
● Q & A – 20m

3. What is the workshop about?
Why TDD?
Should I write unit test for getter/setter?
When should I use mock library?
How do I write tests for static methods?
The problem is complex, where do I start?
I have a tight deadline … can I write tests later?
Is 100% test coverage a myth?

4. Break for coding session

5. Agile
● Individuals and interactions over Processes and
tools
● Working software over Comprehensive
documentation
● Customer collaboration over Contract
negotiation
● Responding to change over Following a plan

6. TDD

7. Refactoring
● Code refactoring is a "disciplined technique for restructuring
an existing body of code, altering its internal structure
without changing its external behavior",[1]
● undertaken in order to improve some of the nonfunctional
attributes of the software.
● Advantages include improved code readability and reduced
complexity to improve the maintainability of the source code,
● as well as a more expressive internal architecture or object
model to improve extensibility.

8. Red bar patterns
● One step test
● Starter test
● Explanation test
● Regression test
● Do over

9. Green bar patterns
● Isolated tests
● Fake it
● Triangulate
● Obvious implementation

10. Smells for bad tests
● Long setup code
● Setup duplication
● Long running tests
● Fragile tests

11. When should you delete tests?
● Confidence
● Communication

12. What have we learned?
Why TDD?
Should I write unit test for getter/setter?
When should I use mock library?
How do I write tests for static methods?
The problem is complex, where do I start?
I have a tight deadline … can I write tests later?
Is 100% test coverage a myth?

13. How Does TDD Relate To
Patterns?
“Another relationship between TDD and patterns is TDD as
an implementation method for pattern-driven design. Say we
decide we want a Strategy for something. We write a test for
the first variant and implement it as a method. Then we
consciously write a test for the second variant, expecting the
refactoring phase to drive us to a Strategy. Robert Martin and
I did some research into this style of TDD. The problem is the
design keeps surprising you. Perfectly sensible design ideas
turn out to be wrong. Better to just think about what you want
the system to do, and let the design sort itself out later”
- Kent Beck

14. Few links
● http://martinfowler.com/bliki/ComposedRegex.h
tml
● http://blog.flimflan.com/ReadableRegularExpres
sions.html
● http://martinfowler.com/articles/mocksArentStub
s.html