TDD Workshop

By Gopal Shah

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

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?

Break for coding session

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

TDD

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.

Red bar patterns

● One step test

● Starter test

● Explanation test

● Regression test

● Do over

Green bar patterns

● Isolated tests

● Fake it

● Triangulate

● Obvious implementation

Smells for bad tests

● Long setup code

● Setup duplication

● Long running tests

● Fragile tests

When should you delete tests?

● Confidence

● Communication

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?

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

Few links

● http://martinfowler.com/bliki/ComposedRegex.html

● http://blog.flimflan.com/ReadableRegularExpressions.html

● http://martinfowler.com/articles/mocksArentStubs.html