I started thinking about some of the bigger names in the developer community and how polarizing they can be due to their hard line positions on topics.  One of the topics that came to mind was Test Driven Development, and how the advocates of it almost always have a strict stance on the correct ways to approach it.  Outside-in or inside-out.  Only one assertion per test or assert one logical concept.  Mocks vs stubs. State vs behavior. TDD or BDD, or is there is really even a difference.

My wife pet-sits, and as she is cooking, so she likes to watch shows which cover training pets, similiar to how one might listen to podcasts as they drive to work.  I will occasionally over-hear, or catch parts of these shows myself, usually while helping her in the kitchen. I also recently read Switch: How to Change When Change is Hard, by Chip and Dan Heath which has a section discussing the importance of reinforcing positive behavior when trying to encourage change and establish habits.  Thinking about the hard-liners and TDD, I realized Kent Beck created the perfect “training clicker” for developers.  Whether this was intentional or not at the time will be something I leave for him to answer.

To train by positive reinforcement, one has to capture the desired behavior and immediately reward it.  When one test drives their code they are encouraged to run their test after each change to see if their change works.  As unit tests are supposed to be fast, this gives the user immediate feedback to know if what they did worked or did not.

The majority of the test runners use either one of two words depending on the result of the test: success or failure.  These two words are very emotionally charged.  Combine this with the fact that they are usually printed in all caps and followed by a number of exclamation points results in output like:
SUCCESS!!!
or
FAILURE!!!

Can’t you just see the emotions getting charged.

Add on to this a graphical user interface for the test runner, or even add ons which change the console text color depending on the end state of the test runs, which use the colors green and red for successes and failures respectively, and you get even more emotional resonance.  You have now gone from the above results to something along the lines of
SUCCESS!!!
or
FAILURE!!!

How is that for evoking an emotional response? I believe I have even heard Kent Beck talking about the thrill he sees in seeing the status bar turn green.

Also, the proponents of TDD encourage small units of work.  The reason being, when you work in minimal units of change you know pretty much exactly what caused the test to fail.  There ends up being a hidden effect to this though.  When you work in small units between test runs, that behavior is now getting reinforced even more frequently, and engraining that behavior more deeply.  Do this enough and that behavior will eventually turn into a habit. And our self-serving egos love to rationalize why our habits are the right thing to be doing, lest we allow ourselves to realize we might be acting wrongly.

And I do not think this just applies to those that are strong proponents for TDD.  Do we ever consider that someone who is a strong opponent may have been negatively reinforced by TDD?  Might they have tried on their own with no guidance and gotten frequent feedback of failures?  Maybe they tried at the wrong level of abstraction, or on a codebase that was not designed with testability in mind. Maybe the test runner just kept giving them negative reinforcement on what they were doing until they decided that TDD is a waste of time.

I am putting this idea out there not to cast judgement against TDD, as it is a practice that I believe has a large amount of value to it, and would love to get good at, but as a something to think about.  Maybe this will help the each side see why the other side might feel they way they do about TDD.

I would love to know your thoughts on this.