James Grenning的动态

I tried TDD for years—and this is what no one tells you: 1) Full coverage isn’t a shield—it just looks nice on paper. 2) Bugs love slipping past the most confident tests. 3) Maintenance is harder when your tests don’t tell the story. 4) TDD only works if you stick to it—and most don’t. 5) The best developers aren’t the ones with 100% coverage—they know where it matters. 6) Code evolves faster than tests can keep up. 7) Unit tests don’t find all bugs—just the ones you thought of. 8) Writing tests can save others more time than it saves you. 9) Unit tests document your assumptions more than your logic. 10) Sometimes deleting old tests is the smartest move you’ll make.

"The main goal of TDD is that we're driven by specifications" and that's a communication challenge. I've seen processes where writing tests clarified expected behaviors and changed the way development and future reviews happened. You write exactly what you expect from code and we can debate on it way before we start implementing. Also, if the specifications change, the tests should change and the current design should fail. And that's a great thing! This means that the specification change 1 - was real 2 - was properly implemented in the test. If the tests pass after a specification change, something's wrong. The last part to solve is not writing frail tests which aim to cover the specifications, but end up testing implementation details.

While 100% code coverage can be achieved, it can be meaningless without proper assertions or relevance. TDD focuses on ensuring the code is well-designed and aligned with user requirements, with high coverage being a byproduct, not the goal. Chasing metrics like coverage can lead to ineffective tests, while true TDD ensures meaningful, quality-driven development.

Part of the problem is legacy code. Even if we wrote perfectly testable code from here on out, we often still have to deal with legacy code. If you need help with that in LabVIEW I’ve got a bunch of effective tools and techniques. I’m working on a refactoring workshop among other things. If that sounds interesting let me know and I’ll add you to the waiting list.

My experience is that the major obstacle in practicing TDD is our innate propensity to overbid on work and go for the big batches. The only way to do TDD properly is to learn how to work in tiny batches.

What really pisses me off about the way TDD is usually taught / demonstrated is how the REFACTOR part is simultaneously downplayed as "just refactoring" and yet at the same time it magically does all of the design for you. In my experience the developer still has to do all of the design, and that's far from being a beginner level skill. Conversely, every refactoring move has an inverse, and so refactoring by itself is agnostic to code / design quality. In most TDD demonstrations I've seen, the exercise is sufficiently small that the resulting design is either trivial, or was worked out beforehand, or is terrible (bowling scores kata, much?). TDD is just as difficult as good software design. Rant over (for today) ??

A quick demo of four-step TDD. I'll follow up with more as I put them together.

To TDD or not to TDD really shouldn't be up for debate. At the very least, write some tests for your code. Maybe you start with code followed by the tests, OR the tests followed by code, just make sure to test your code. Stats show that #Devs that test their code tend to live longer. Actually, I'm not sure about the stat above, (which I also made up), but I'm sure about the assertion that follows below. Your SLEEP will definitely improve! That, I'm certain! #softwareengineering

To grasp TDD, you have to hold two seemingly contradictory truths in balance: - TDD is meaningless outside the context of delivering concrete value to real people. - While testing starts at the level of validating actual usefulness to such real people, stopping there leaves 80% of the value of TDD on the table. That is, you are equally wrong if you engage in testing simply because you think it’s the right thing to do or if you write only feature tests without going deeper into the semantic layering of the system as it evolves. Philosophy and an ability to reason aren’t just important when it comes to code monkeying, you also need to be reasoning well about the practice itself.

TDD slows you down?! It's because of you, not TDD. TDD makes you faster if you do it well. But to experience the sweetness, you need patience. You need to invest time to learn TDD. Embrace the learning curve. Master writing tests and designing code. It's one of the best investments you can make in 2024. To learn TDD, check out Daniel's new TDD course: https://lnkd.in/enEwhPbQ