Does it matter what we call it?

Do what you want, but if your goal is to communicate clearly, don't call it by the established name.

I’ve recently been involved in a number of lengthy threads on social media about misunderstandings regarding the concept of “continuous integration”. There are a number of misunderstandings around this term. The most common being that simply installing Jenkins, or configuring GitHub Actions means you “have CI”.

Continuous Integration (and for that matter, continuous delivery and continuous deployment) is something you do not something you have.

Eventually, in virtually every conversation like this, someone will come along and say “Okay, so I’m not doing exactly the thing you describe. I’m doing this slight variant, that I believe works well for me, and we’ve been calling it CI. I don’t see any problem with that.”

So is that legitimate?

Well, on the one hand, sure… Do whatever you want, or whatever you think is best in your situation.

But on the other hand… don’t call it by the established name in that case. That just leads to confusion. Need an example? How about the article I responded to yesterday, _Test-Driven Development is Fundamentally Wrong? This is a great example of miscommunication due to a disagreement on the meaning of terms.

Kent Beck, often credited as inventing TDD, describes TDD as:

  1. Write a list of the test scenarios you want to cover
  2. Turn exactly one item on the list into an actual, concrete, runnable test
  3. Change the code to make the test (& all previous tests) pass (adding items to the list as you discover them)
  4. Optionally refactor to improve the implementation design
  5. Until the list is empty, go back to #2

Chris Fox describes it as:

  1. write the TDD tests
  2. begin implementation
  3. discover an unanticipated consideration
  4. rewrite the tests
  5. continue implementation
  6. goto 3 over and over and over …
  7. (actually more like item 150) all tests pass
  8. send to QA

My point here isn’t which one, if either, is “right” or “wrong”, only that they are different. Perhaps most notably in that Beck’s version has you write a single test at a time, whereas Fox’s version has all the tests written up front… and then rewritten one at a time. Calling both of these, very different, practices “TDD” will (does) lead to confusion.

So… do what you want. Write all your tests first. Have 6-week long feature branches. Use Gantt charts. Plant hydrangea in your garden.

But, if your goal is to communicate clearly, don’t refer to these as test-driven development, continuous integration, agile, or roses.

Share this