1. 11
  1.  

  2. 4

    I’m a bit surprised to see this article published now. The TDD dogma seem to have faded away years ago.

    1. 1

      I thought the same thing, but I wasn’t sure how much of it was that I stopped listening to people who were all-in on the Next Big Thing and how much was that it actually died off.

      I guess it’s good that the author has come to the realization that there is nothing that fits every scenario.

      1. 0

        One thing that hasn’t faded…..

        The same bad old percentage on untested branches that have bugs in ’em.

        So long as you’re prepare to brutally honestly look at your own personal rate of defects per branch written…. and multiply that by the number of your untested branches and honestly say, “I’m OK and my customer is OK with (at least) that many defects left in my code.”

        In which case no TDD dogma is needed.

        Everyones happy.

        However, if that brutally honest answer makes you or your customer uncomfortable…

        If somebody doesn’t get to see the cat picture granny sent them…. yup, dogma isn’t needed.

        If the risk to somebodies life is increased…. Well, you’re going to need some TDD dogma and a bunch of other things.

      2. 2

        From one of the comments below the article:

        To me this sounds like you’ve completely missed the point of TDD.

        This is the same back-and-forth navel-gazing that’s seemingly been the focus of the “software craftsmanship” community for at least the past five years.

        TDD is great and all, but when are we going to get over ourselves?

        1. 8

          I encourage you to first start with the mentality “TDD is always viable” and try to pick out flaws in your process that are hindering it.

          Oh my.

          1. 1

            I’m not sure there is a problem here…..

            There has always since the XP days been the notion of an Architectural Spike.

            All seat belts off, no tests, coding standards out the door, cowboy to the max…. get the info you need to understand the external system / framework / Tool whatever.

            Then throw it away and do it right.

            Then, in this case, you TDD collaboration tests..

            ie. You test that your code and the external system agree on the interface.

            ie. You test your can handle everything the external system throws at you, and you can handle every error condition the external system may return.

            1. 7

              When people say “you’re not doing TDD right”, they mean a specific interpretation of TDD: the strict minimalist red-green-refactor as a form of design. “Test everything” or even “write tests before your code” don’t “count” as “real TDD”. So saying “TDD is always viable” is saying “this specific set of rigid rules is always a good choice”, which is… bad.

              1. 1

                In the category of “Throwing a Mental Grenade into the Conversation and running away giggling…”

                Kent Beck’s latest adventure is… test && commit || revert

                https://increment.com/testing/testing-the-boundaries-of-collaboration/

                Which actually might be a fun experiment to try.

          2. 5

            Every time I see a criticism of TDD the response is “you don’t understand TDD” or “you’re doing TDD wrong”, to the point where I’m wondering what the hell TDD even is.

            1. 8

              Dismissing criticism with a hand-wavy “you are doing it wrong” seems to be popular in the Scrum/Agile circles too. It reminds me a lot of https://yourlogicalfallacyis.com/no-true-scotsman

              1. 2

                I’ve done a lot of TDD, so I’d say it’s:

                1. Write a test that fails (either for a feature that doesn’t exist yet or that reproduces a bug)
                2. Write minimal code that makes the test pass, no matter how ugly or WET
                3. Refactor (this is where design happens)

                Other than that the only other rule is to not write production code without a test to motivate/cover it.

                In my experience people dismiss seeing the test fail, but it’s extremely important.

                1. 3

                  In my experience people dismiss seeing the test fail, but it’s extremely important.

                  This to me is one of the two truly valuable things you gain from TDD: if you always make the test fail first, you never fall into that nasty trap of having both buggy code and a buggy test, which makes debugging the thing at midnight when the page comes in so much worse. It’s so tempting and easy to see a bug report come in and think, “I know what caused that,” and change the production code. Now maybe you also write a test, but the test passing doesn’t necessarily tell you much. Even if you do things in this order, commenting out your changes once you write the test (to prove that it can fail) gives you the same benefit. Extremely useful, IME.

                  The other main benefit I think is a tendency to write functions/methods which return values, rather than mutate state or produce side effects, which is of course not limited to TDD but in some idioms that are lax about side effects/mutability, TDD can help you avoid the temptation to just mutate state all over in eg a big Rails controller method or something.

                  These 2 things I have personally found very valuable in my career; all the other dogmatizing I find sensationalized.

                  1. 2

                    if you always make the test fail first, you never fall into that nasty trap of having both buggy code and a buggy test

                    Precisely. As Sean Parent said in his CppCon 2019 talk, it’s like double-entry bookkeping in accounting.

                    These 2 things I have personally found very valuable in my career; all the other dogmatizing I find sensationalized.

                    Atila’s rule #0 of programming: use your head. I mostly TDD, but sometimes I don’t. It’s always about trade-offs.

              2. 4

                TDD is basically 1% of software developers aggressively shouting that the other 99% are wrong, stupid, incompetent, and “may wind up fired and in jail” for not using TDD 100% of the time.

              3. 1

                Let’s not risk the design bug while avoiding the implementation bug.

                1. 0

                  I see the point the article tries to convey. TDD is still very beneficial when we are sure of our design / architecture / workflow. TDD should only be used when implementing a code portion with known inputs / outputs. When not possible, the code should be integration / e2e tested instead.