What Does “Proficient” at TDD Look Like? | Hacker News Reader

What Does “Proficient” at TDD Look Like?

1 pointlancerkind6 comments

When we say someone is proficient at TDD, what outcomes have they achieved? What capabilities do they have?

I’ll take your suggestions to put together another TDD episode for Agile Thoughts

http://agilenoir.biz/en/agilethoughts/why-developers-dont-tdd-a-radio-drama/

Here is what I’ve got so far.

You’re proficient when (scroll left to right to read):

  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.

You are a master when:

  You can teach others how to become proficient.
  Your team’s project has very good code coverage (> 80%) and still

View on HN

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".

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-... 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/

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.

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.

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?

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.

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

Reply on news.ycombinator.com