When a new team spins up at Pivotal time is set aside to get everyone onboard with the basic principles of XP, SOLID and TDD.

Today we walked through TDD. Here are my notes.

Agenda

  1. history
  2. why
  3. kata

History

  • silicon valley computer history museum
  • 1959 space program
  • late 80s. spreadsheet testing.
  • 1994 sunit. kent beck. xp visionary.
  • 1998 junit. kent beck. user stories. acceptance criteria. requirements gathering.
  • 2001 jbehave. dan north. behaviour driven development. turning the customer facing conversation directly into the code and test suite.
  • 2008 Cucumber.

Trying to find better ways of specifying what software should do.

“unit tests are inside out. behaviour tests are outside in”

Kent Beck & Pivotal

around 1998. pivotals founder worked with kent beck. this is why pivotal holds this practice so core. pivotal one of the first xp companies in the world.

that beautiful moment of writing the test first.

Why

  • clean
  • confidence to refactor
  • self documenting
  • focus. less context shifting.
  • flow
  • more fun (ping pong, the evil coder, mute pairing)
  • doing just enough
  • code readability

“TDD is not the end game. We are not just following instructins. We do it for a specific reason. We want teams to go fast forever.””

Why did “Team D” start off as fast and then slow down?

Because they were put in front of bad code. This depends on clean code. Speed is directly related to clean code.

Why did “Team C” not clean the code?

Because it is something that needs to be done on a regular basis. Every day. Every push. Keeping your code clean requires ongoing refactoring.

Why did “Team B” not refactor?

Because they did not have confidence to make changes to the code. They were worried they would break stuff.

WHy did “Team A” not have confidence?

Because they did not have tests.

Going fast forever ultimately relies on tests. Given this is so critically important. Because tests are so important. Tests come first.

TDD. Test driven developement. Test first. Code second.

“It’s in the doing of the work, that you discover the work that must be done.” - Woody Zuille

“Make the change easy (this might be hard), and then make the easy change.” - Kent Beck

“All we do all day is learn. Coding is learning. Coding is one of the most mentally exhausting things you can do. Especially if you are not driven by a test suite.” - Parker Matthew

Reservations about TDD

  • proof of concepting. organisational maturity. POC + TDD?
  • impact on design. often tightly coupled to design patterns.
  • go slower
  • tests can’t cover everything
  • twice as much code
  • we already have QA! why double that?
  • our tests take 24hrs to run. many failures. test suite bankrupcy.
  • sharp learing curve. hard to learn how to do tdd well.
  • pairing and tdd is too expensive.
  • pairing is exhausting.

Is it faster to Pair + TDD?

Pivotal has researches in standford doing stats on performance of pairs against individuals shipping code. They discovered that individuals focus 10% - 20% of the day. Pairs focus 80% - 90% of the day.

Pairing helps remove silos, knowledge share.

“We want you to have to kill all the engineers on the team before you have a problem. #BusCount”

Style

  • London. Spy and observe messaging and connection.
  • Detroit. Stateful observation.

Notes

  • Test on the left or the right? Left. People read left to right.