TDD Isn’t Hard, It’s Something Else…

🚨 25% OFF MY ONLINE TDD COURSE | LIMITED TIME ONLY | I’ve put 25+ years of training and consultancy experience into creating a course specifically designed to accelerate your understanding and application of TDD. Studying with me HAS NEVER BEEN EASIER, and until Friday the 14th, you can get £150 OFF the price. Find out more HERE ➡ https://courses.cd.training/courses/tdd-bdd-design-through-testing

No Dave ! Not you ! Not this "study" ! They were NOT doing TDD ! That's why it was soooooo hard for them and longer. I quote the study :

IBM : "With the TDD group, test cases were developed mostly upfront as a means of reducing ambiguity and to validate the requirements, which for this team was a full detail standard specification. UML class and sequence diagrams were used to develop an initial design. This design activity was interspersed with the up-front unit test creations for developed classes. Complete unit testing was enforced—primarily via reminders and encouragements. We define complete testing as ensuring that the public interfaces and semantics of each method (the behavior of the method as defined by the specification) were tested utilizing the JUnit2 unit-testing framework. For each public class, there was an associated public test class; for each public method in the class there was an associated public test method in the corresponding unit test class. The target goal was to cover at least 80% of the developed classes by automated unit testing."

Microsoft : "The TDD team at Microsoft did most of their development using a hybrid version of TDD. By hybrid we mean that these projects as with almost all projects at Microsoft had detailed requirements documents written. These detailed requirements documents drove the test and development effort. There were also design meetings and review sessions. This explains our reason to call this a hybrid-TDD approach, as agile teams typically do not have design review meetings"

We programmers are never required to provide a warranty against future defects found in our Production code. Nor are we rewarded for writing Clean and maintainable (same thing really) code, but for meeting deadlines so we can go onto the next project. And also for learning the latest frameworks and libraries and tools, to polish our resumes for our next job. That adds up to a lot of distractions. So, here is the proposition I put to you, fellow professionals: "Do you take pride in your work?"

In the past 7 years I have worked with a couple of hundred Java programmers all over the world. Only two of them wrote automated tests unless management forced them to – after the fact – to get 80% code coverage. My code reviews with junior and medium programmers rarely had an effect on code quality beyond the Pull Request Classes. But in a few cases the programmer started writing code that they were proud of. However, TDD is still a long way off.
Dave's audience doubtless includes a lot of proud professionals. We have a lot more work to do.

Write the tests in the implementation language. If you can't do that, use another language, or admit you're doing some BDD/TDD hybrid (in Dave's example).

One of the issues for TDD is that the languages we commonly use were not designed for it, so it is easier to code without doing TDD.

The code example is horrible.

I like that TDD forces you to think first about good APIs and contracts. Also about how responsibility is divided between parts of the code. But once you can do that on your own, you can ignore the rest of TDD.

Great video to watch while I'm using TDD and while it is paying dividends. I'm reverse engineering some software for which i don't have the source. The original software can export it's config as a text file. Using TDD i was able to find bugs in my code but also find bugs in the original authors code. I was working with a binary file and offsets of the data change depending on the type of record. TDD made it easy to get that right. I discovered i made a spelling mistake deep into the build. It turned out to be all over the code and tests. TDD allowed me to correct this and ensure i didn't break existing code. The hardest part has been ensuring that i have the discipline to stay the course. Thanks for the leadership on TDD. 16:03

I think one common barrier to TDD is actually to setup the testing. Application starts with system.out.printlin("hello world"), and testing for side effects may be not nearly obvious . Okay hello world is not our business case, but what if i want to test logging, which may be part of the business requirement as security audit relevant stuff? You have to hope that someone has already done that, and there is an instruction somewhere on how to do it correctly. With correctly, i mean writing such tests may require above average understanding of the underlying technology. Not every average java backend developer has ever touched any logback.xml file. This forces you to lift up your understanding of your programming environment. And that is where abstractions get ugly. How many java developers know how JVM works? And how many know how to test that, what others tell them about how JVM works is true. Our tech stacks became so opaque, that even when you write unit tests you may not really know what you are doing exactly. I think proper unit-testing has much seeper learning curve as our convinient testing tools suggest.

I once was writing a command line analyzing utility for AD printouts, and my fist quest was to find a CLI library which brings testing capabilities to the table. So that i could effectively test for command line inputs. And there were only few of them. If you are not lucky to work with "unit-test enabled" libraries or frameworks, the whole TDD approach may turn out into a challenge of fiddling around and getting the wirings for the TDD right, instead of focusing on the actual user value of the application. This would make it difficult to advocate for TDD.
For me this is a core challenge, not knowing how to do it correctly (testing the right thing) for non-mainstream situations.

Software development today includes provisioning cloud resources with terraform or some other IAC software. How would you TDD cloud infrastructure, for example a simple real-time data pipeline with kinesis, lambda, and SQS?

Or is TDD irrelevant for provisioning cloud resources?

I have noticed, when running workshops, that folks seem numb to the design choices they make and thus don't seem to benefit from TDD.

It's not hard to do, it's hard to contextualize. I recently started a small vending machine project, and it involves code. I put that code on Github – does this code need to be done with TDD? Given that you are supposed to start with TDD, why would a small python project I built specifically as something to build with my kids need TDD? How much time do I set aside to try and test hardware – like a coin acceptor's inputs for different sizes coins – for a project that is meant for fun? The code is a small, almost insignificant aspect of the project.

In other words, a lot of larger projects start from humble beginnings, and they often start in a single script, or CLI that just does something simple. In my experience, most projects don't begin with a thoroughly written requirements document – where beginning with TDD makes obvious sense. I think a lot of this TDD evangelism misses so many examples of cases where TDD from the start would seem pedantic and almost a bit narcissistic.

If you did not test it, it does not work

Id like to do tdd but always working on massive legacy classes 😢

TDD Isn't Hard, It's Something Else…
😏

Oof, the sneaky plugs are a little off putting, but good video outside of that