I need to convert my development team to a "test first" mindset. Pro-"test first" Voats, how was your team converted? Anti "test first" Voats, tell me your criticisms so that I can prepare for them.

6    07 Jul 2015 21:19 by u/Mechrophile

Thanks for your time!

We have a lot of legacy code, and zero test coverage. zip. My job is to fix that. I mean literally, my paycheck will hang on whether or not I can lead our company into a well tested future. I have decided that we will be adopting Michael Feather's "Test first" approach for solving this problem: that is, TDD. I know there's a lot of resistance to TDD, but we need a unified direction, and this is the one we'll be taking.

We're a python shop, tech startup. small team (hello, coworkers who recognize this)

What say you, Voats?

4 comments

2 u/sychian 07 Jul 2015 22:34

When you say small team, I'm assuming fewer than 6 developers. In that case, I would suggest introducing it by pairing, one at a time with each developer over the course of several features/enhancements/whatever units of work you have. Demonstrate to each one the benefits and pitfalls by directly working with them on their day-to-day efforts.

So that's my "mechanics" answer. What about the "hearts and minds" piece? Likely the biggest risk to adoption is that people start to think TDD is slow. This is even worse in your case because you can't "TDD" legacy code. The code is already there. You can make sure you write tests for the legacy code before you write any new code. Then you can use TDD for the new code. What this means, however, is that you're initially going to be "slowing down" even more than using TDD normally would.

How do you fight this? Don't talk about TDD as being about speed. Talk about it in terms of safety and design. Talk about the reduction of stress involved with making future changes because of the "safety net" that the test suite provides. (Note: I am assuming you will have a build that runs all tests on every check-in/commit/push to the code repository. I am also assuming you are using version control.) Talk about how writing the tests first ensures that your design is minimal and aids in getting the design to be as flexible as possible.

There are whole books on this, so I'll end by recommending one you may have seen since you mention Michael Feathers: Working Effectively with Legacy Code.

0 u/Mechrophile [OP] 08 Jul 2015 16:56

I thought I mentioned that I was using Michael Feather's approach in my post. Definitely a great book. Defining legacy code as "code without tests" is a great step. The way he defines unit tests as fasts and error localizing is genius.

1 u/Shammah 08 Jul 2015 15:13

See Erik Meijers video last posted here which dicusses some of the reasons why you shouldn't do TDD. I'd take a milder approach. Try to make as much tests as you go aside from trivial stuff, and when solving bugs, don't push the fix unless there's also a test case that passes with it. It keeps your mind from going insane from the boredom of writing tests. Besides, software evolves and changes, so a lot of time on creating tests beforehand is a waste.

1 u/ejrado 08 Jul 2015 16:45

I would suggest that you have the infrastructure in place first - daily builds or hourly builds. I know you're in python, but a build includes running all unit tests. If any test fails, the build fails.

In the past, I implemented a $1 'fine' for causing the build to fail. After x amount of time, we'd have a pizza/beer party.

To me, the beauty of TDD is twofold:

  1. CYA - if your test passes, then your code is good. I'm dealing with an issue right now where another dev forgot to update stored procs. My tests previously passed but now are failing. But I can point to my test and say this worked previously. And provide an easily reproduceable way to find what's wrong.

  2. Simplified development. When your test passes, you're done. Period.

I also concur with sychian about paired programming. It's a great way to learn TDD.

Edit: a word