
What Does “Proficient” at TDD Look Like? - lancerkind
When we say someone is proficient at TDD, what outcomes have they achieved? What capabilities do they have?<p>I’ll take your suggestions to put together another TDD episode for Agile Thoughts<p>http:&#x2F;&#x2F;agilenoir.biz&#x2F;en&#x2F;agilethoughts&#x2F;why-developers-dont-tdd-a-radio-drama&#x2F;<p>Here is what I’ve got so far.<p>Here is what I’ve got so far.<p>You’re proficient when (scroll left to right to read):<p><pre><code>  You can write a dozen tests in an eight hour day.
  You are have refactored 4 big functions or classes to make them testable. 
  You bristle at any suggestion of skipping writing tests.
  At least a week has passed since when you last used the debugger.
</code></pre>
You are a master when:<p><pre><code>  You can teach others how to become proficient.
  Your team’s project has very good code coverage (&gt; 80%) and still</code></pre>
======
eesmith
These also apply to test-last developers.

Eg, suppose I write all the code and don't write the tests until the end. Then
I spend 5 weeks writing tests.

I can easily write dozens of tests in an 8 hour day, and refactor code to make
it more testable. I'm still writing tests, so bristle at the suggestion that I
should. I'm using coverage to help figure out which tests to write, so I'm
easily going to get 80% or better.

My own style is much closer to "Spike and Stabilize", and not TDD, yet all the
things you wrote also apply to me.

FWIW, I almost never use the debugger, even without doing TDD, as I use print
statements. Even with TDD, for some people the debugger is used as a way to
understand/explore the interface to other libraries.

BTW, I see no mention of "mantra" of "red/green/refactor".

~~~
lancerkind
Nice points here.

I'll have to do a show on "spike and stabilize." This strategy of "late"
refactoring and micro testing is something we are forced to do when
encountering untested legacy code. So this as part of the "tool kit" to be a
master and difficult for someone who is proficient.

My perception is that Spike and Stabilize, always takes longer than TDD
because:

    
    
      1) I have to spend time "re-discovering" what the code is supposed to do in order to write the test.  
      2) If I need to use the debugger or print statements to learn what the code is doing, 
         these temporary diagnostics aren't automatable and the value achieved
         can't be checked into source code.  
      3) I have to work harder at bad design decisions that occur when not thinking about unit testing. 
      4) I find APIs aren't as intuitively crafted because TDD forces you to define your interface 
      to get started (a simple version which evolves as needed) rather than 
      the steps of: "write code, get it working, go back and refactor and test"
      5) The costs increase with Spike and Stabilize with the time delta between
      the moment the code is written to the moment tests are added.  
      6) Plus Spike and Stabilizes allows people to be pressured into doing the
      wrong thing: ship it now, worry about test automation later.  
      If you're disciplined, this won't matter because you can simply say no.
      If you're not, test debt increases.  TDD removes this possible risk.
    

Thank you for the suggestion on explicitly adding the TDD "mantra" of
red/green/refactor. In episode 22, TDD with a Stack Overflow Master Developer,
it explores TDD versus Spike and Stabilize Later in a dramatic presentation:
[https://agilenoir.biz/podcast/022-tdd-with-a-stack-
overflow-...](https://agilenoir.biz/podcast/022-tdd-with-a-stack-overflow-
master-developer/) This story of a developer going through the challenges of
getting his team to do TDD starts with episode 14:
[https://agilenoir.biz/series/agile-
thoughts/](https://agilenoir.biz/series/agile-thoughts/)

Thank you for the name, "spike and stabilize." It _sounds_ better than "Test
Later Strategy" but I fear it obscures the risky and uncertain future.

~~~
eesmith
Kent Beck include spikes as part of TDD practice, specifically as a method to
reduce risk in an uncertain future.

In order to argue your point 1), don't you have to say that spikes are not, or
no longer, part of TDD?

The difference is that traditional spikes are discarded ... which means you
have to spend time "re-dicovering" how the code works anyway, yes?

Concerning 2), my point stands that your original statement 'At least a week
has passed since when you last used the debugger' is not a key indicator of
proficiency at TDD.

The rest of your response is advocacy for TDD and "perceived", not a
description of how to tell if someone is an expert at TDD, nor necessarily a
correct approach for most people. As such, I can only say that my perceptions
are different.

Your #6 specifically uses TDD as a negotiation tactic, rather than than as a
good engineering practice. That is, the "removes this possible risk" you refer
to is personal CYA risk. This is different than the business risk. While those
are certainly correlated, good engineering considers the overall economic
factors.

In this respect, TDD is especially useful for programmers as programmers
usually have less negotiation experience than their managers, and especially
less than managers from marketing and sales (to say nothing of the CEO) who
are providing the pressure. Pointing to an external guru who says "TDD is the
only professional way to do software development" gives these (usually junior)
programmers the leverage to do reasonable testing.

Since I am not in that situation, I can choose the development approach which
I believe is most appropriate. Which isn't TDD.

~~~
lancerkind
About Spikes: They are a tool to be employed when no one on the team has
confidence in how to solve a technical problem. Spikes are used to deliver
learning through doing. They are a Plan B. Used when we can't do Plan A--write
the tests and the code with TDD. Because it takes longer to write tests later,
the Spike is a simple implementation to learn something. Once the learning has
happened, then you go into the code and use TDD to develop the product code.
The spike code is never meant to be product code.

Don't you think it's a misuse if ALL of your development is using spikes?

Don't you think that this use of Spikes is a crutch to avoid something you are
unmotivated do and haven't invested time to learn?

------
kalyantm
I think it boils down to the fact that they think "tests first", which means
they can visualize the module/software that is being built. All the inputs and
outputs and how the software is supposed to work. That being said, if the
requirements change too often, its hard for anyone to try and be proficient in
TDD.

~~~
lancerkind
So "thinking test first" means you've reached proficiency. How would you
observe "thinking test first" behavior?

