As with any new practice, I would expect the team to slow down a bit while learning. If the team already writes lots of tests, the slowdown may not be all that much. It might be wise to have TDD days for a while, where folks practice TDD and other days where they do not, but I’d only do that if the slowdown seemed way too much.
When you’re good at TDD, you’ll likely go faster than you did without it, because TDD reduces defect insertion and excess work, so one generally goes faster to working code with TDD. Of course if the code doesn’t have to work … we could ship it now and save lots of time.
I would not think in terms of metrics. Instead, I would have team sessions where the whole team assesses some tests and code on a screen, discussing their observations about the test and code quality.
Of course, you may be thinking “But how will we know what to think and discuss?” And that brings me to the question that you didn’t ask:
0. What is the best way to get our team started with TDD?
To that I would answer that the best way to learn TDD is in a class especially designed to teach it, with an expert instructor guiding the class. I can’t name all the experts whom you might pick, but a few include Dave Farley, Ted Young, J. B. Rainsberger, and James Shore. If you’re an embedded C or C++ shop, I’d add in James Greening to that list. I’m sure there are others who just didn’t come to mind, but I do think you should be sure to get a real expert: TDD is not what most people think it is.
Good luck!
R
Ron Jeffries
Sometimes people just don't want the flower. Sometimes you have to let them walk away.
— Amanda Palmer