I have complicated feelings about TDD

The trouble with TDD is that quite often we don&#x27;t really know how our programs are going to work when we start writing them, and often make design choices iteratively as we start to realize how our software should behave.<p>This ultimately means, what most programmers intuitively know, that it&#x27;s impossible to write adequate test coverage up front (since we don&#x27;t even really know how we want the program to behave) or worse, test coverage gets in the way of the iterative design process. In theory TDD should work as part of that iterative design, but in practice it means a growing collection of broken tests and tests for parts of the program that end up being completely irrelevant.<p>The obvious exception to this, where I still use TDD, is when implementing a well defined spec. Anytime you need to build a library to match an existing protocol, well documented api, or even an non-trivial mathematical function, TDD is a tremendous boon. But this is only because the program behavior is well defined.<p>The times where I&#x27;ve used TDD and it makes sense it&#x27;s be a tremendous productivity increase. If you&#x27;re implementing some standard you can basically write the tests to confirm you understand how the protocol&#x2F;api&#x2F;function works.<p>Unfortunately most software is just not well defined up front.

TDD use would be a lot different if people actually bothered to read the entirety of Kent Beck&#x27;s _Test Driven Development: By Example_. It&#x27;s a lot to ask, because it is such a terribly written book, but there is one particular sentence where Beck gives it away:<p>&gt; This has happened to me several times while writing this book. I would get the code a bit twisted. “But I have to finish the book. The children are starving, and the bill collectors are pounding on the door.”<p>Instead of realizing that Kent Beck stretched out an article-sized idea into an entire book, because he makes his money writing vague books on vague &quot;methodology&quot; that are really advertising brochures for his corporate training seminars, people actually took the thing seriously and legitimately believed that you (yes, you) should write all code that way.<p>So a technique that is sometimes useful for refactoring and sometimes useful for writing new code got cargo-culted into a no-exceptions-this-is-how-you-must-do-all-your-work Law by people that don&#x27;t really understand what they are doing anymore or why. Don&#x27;t let the TDD zealots ruin TDD.

The main reason TDD hasn&#x27;t caught on is there&#x27;s no evidence it makes a big difference in the grand scheme of things. You can&#x27;t operationalize it at scale either. There is no metric or objective test that you can run code through that will give you a number in [0, 1] that tells you the TDDness of the code. So if you decide to use TDD in your business, you can&#x27;t tell the degree of compliance with the initiative or correlation with any business metrics you care about. The customers can&#x27;t tell if the product was developed with TDD.<p>Short of looking over every developer&#x27;s shoulder, how do you actually know the extent to which TDD is being practiced as prescribed? (red, green, refactor) Code review? How do you validate your code reviewer&#x27;s ability to identify TDD code? What if someone submits working tested code; but, you smell it&#x27;s not TDD, what then? Tell them to pretend they didn&#x27;t write it and start over with the correct process? What part of the development process to you start to practice it? Do you make the R&amp;D people do it? Do you make the prototypers do it? What if the prototype got shipped into production?<p>Because of all this, even if the programmers really do write good TDD code, the business people still can&#x27;t trust you, they still have to QA test all your stuff. Because they can&#x27;t measure TDD, they have no idea when you are doing it. Maybe you did TDD for the last release; but, are starting to slip? Who knows, just QA the product anyways.<p>I like his characterization of TDD as a technique. That&#x27;s exactly what it is, a tool you use when the situation calls for it. It&#x27;s a fantastic technique when you need it.

I could write an entire blog post on my opinions on this topic. I continue to be extremely skeptical of TDD. It is sort of infamous but there is the incident where a TDD proponent tries and fails to develop a sudoku solver and keeps failing at it [1].<p>This kind of situation matches my experience. It was cemented when I worked with a guy who was a zealot about TDD and the whole Clean Code cabal around Uncle Bob. He was also one of the worst programmers I have worked with.<p>I don&#x27;t mean to say that whole mindset is necessarily bad. I just found that becoming obsessed with it isn&#x27;t <i>sufficient</i>. I&#x27;ve worked with guys who have never written a single test yet ship code that does the job, meets performance specs, and runs in production environments with no issues. And I&#x27;ve worked with guys who get on their high horse about TDD but can&#x27;t ship code on time, or it is too slow, and it has constant issues in production.<p>No amount of rationalizing about the theoretical benefits can match my experience. I do not believe you can take a bad programmer and make them good by forcing them to adhere to TDD.<p>1. <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=3033446" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=3033446</a>

Like almost every spectrum of opinions, the strongest opinions are typically the least practical, and useful only in a theoretical sense and for evolving the conversation in new directions.<p>I think TDD has a lot to offer, but don&#x27;t go in for the purist approach. I like Free Software but don&#x27;t agree with Stallman. It&#x27;s the same thing.<p>The author takes a well reasoned, mature, productive, engineering focused approach, like the majority of people should be doing. We shouldn&#x27;t be applying the pure views directly, we should be informed by them and figure out what we can learn for our own work.

The fact that some people really argue that TDD produce <i>better</i> designs... sigh. Here, look at this [0] implementation of Dijkstra&#x27;s algorithm, written by Uncle Bob himself. If you think <i>that</i> is well-designed (have you ever seen weighted graphs represented like this?) then, well, I guess nothing will ever sway your opinion on TDD. And mind you, this is a task that does have what a top comment in this very thread calls a &quot;well defined spec&quot;.<p>[0] <a href="https:&#x2F;&#x2F;blog.cleancoder.com&#x2F;uncle-bob&#x2F;2016&#x2F;10&#x2F;26&#x2F;DijkstrasAlg.html" rel="nofollow">https:&#x2F;&#x2F;blog.cleancoder.com&#x2F;uncle-bob&#x2F;2016&#x2F;10&#x2F;26&#x2F;DijkstrasAl...</a>

There&#x27;s some absolute nonsense in the TDD style. Exposing internal details for test is recommended and bad for non-test users of the interface. Only testing through the interface (kind of the same as above) means tests contort to hit the edge cases or miss them entirely.<p>The whole interface hazard evaporates if you write the tests in the same scope as the implementation, so the tests can access internals directly without changing the interface. E.g. put them in the same translation unit for C++. Have separate source files only containing API tests as well if you like. Weird that&#x27;s so unpopular.<p>There&#x27;s also a strong synergy with design by contract, especially for data structures. Put (expensive) pre&#x2F;post and invariants on the methods, then hit the edge cases from unit tests, and fuzz the thing for good measure. You get exactly the public API you want plus great assurance that the structure works, provided you don&#x27;t change semantics when disabling the contract checks.

I&#x27;ve always sort of thought of TDD a bit of a software development methodology cryptid. At best you get shaky camcorder footage (although on closer investigation it sure looks like Uncle Bob in a gorilla suit).<p>Lots of shops claim to do TDD, but in practice what they mean is that they sometimes write unit tests. I&#x27;ve literally never encountered it outside of toy examples and small academic exercises.<p>Where is the software successfully developed according to TDD principles? Surely a superior method of software development should produce abundant examples of superior software? TDD has been around for a pretty long time.

One of the biggest issues with our industry is the ambiguity in our definitions. The author mentions “unit tests” as if it was a well defined term. But some people understand “unit” as a class, other understand it as a module, others as a behavior. Some TDDers write unit tests that would be considered “integration tests” by other developers.<p>Then we have TDD itself, there are at least two different schools of TDD. What the author calls “maximal TDD” sounds like the mockist school to me. Would his criticism also apply to the classical school? I’m sincerely curious.<p>If we don’t have a common ground, communication becomes really difficult. Discussion and criticism becomes unfruitful.

My personal mentality about TDD is that it is an unreachable ideal. Striving for it puts you on a good path, but business logic is rarely so straight forward.<p>If you are lucky enough to be writing code in a way that each unit is absolutely clear before you start working, awesome you got it. But in business-logic-land things rarely end up this clean.<p>Personally, I program the happy path then write tests and use them to help uncover edge cases.

A lot of the software engineering approaches from that era (refactoring, TDD, patterns) make more sense in the world I grew up in: large pre-compiled code bases where everything other than the base OS layer is under the engineer&#x27;s control. If you have to ship your SW as an installable which will end up on someone&#x27;s machine far away your mindset will be more defensive.<p>In this day and age of vastly distributed systems where distribution and re-distribution is relatively cheap we can afford to be a little less obsessive. Many exceptions still exist, of course, I would think that the teams developing my car&#x27;s control system might warm up to TDD a bit more than someone putting together a quickie web app.

This has been rehashed a million times.<p>My view is that TDD is great for non-explorative coding. So data science -&gt; way less TDD. Web APIs -&gt; almost always TDD.<p>That said, one of the things I think the vast majority of the leans anti-TDD crowd misses is that someone else on the team is picking up the slack for you and you never really appreciated it. I&#x27;ve joined too many teams, even great ones, where I needed to make a change to an endpoint and there were no functional or integration tests against it. So now <i>I&#x27;m</i> the one that is writing the tests <i>you</i> should have written. <i>I&#x27;m</i> the one that has to figure out how the code should work, and <i>I&#x27;m</i> the one that puts it all together in a new test for all of your existing functionality before I can even get started.<p>Had you written them in the first place I would have had a nice integration test that documents the intended behaviour and guards against regressions.<p>Basically I&#x27;m carrying water for you and the rest of the team that has little to do with my feature.<p>Now there are some devs out there that don&#x27;t need TDD to remember to write tests, but I don&#x27;t know many of them and they&#x27;re usually writing really weird stuff (high performance or video or whatever).<p>But I have stopped concerning myself with changing other peoples minds on this. Some people have just naturally reactive minds and TDD isn&#x27;t what they like so they don&#x27;t do it.

I like TDD. It’s just a tool on our tech belt. If done right (takes practice and open mind tbh) the major benefit is you have code that is single responsibility and easy to understand, isolate, or modify.<p>We have so many things on our tech belt, like clean architecture or x pattern. This is just another tool, and I think it helps especially in building complex software.<p>Just be practical and don’t try to be “the 100%er” who is super rigid about things. Go into everything with a 80&#x2F;20 mindset. If this is something mission critical and needs to be as dependable as possible, then use the tools best suited for it. If you’re literally putting buttons on the screen which Product is going to scrap in two weeks, maybe use TDD for the code responsible for dynamically switching code based on Product mindset that week.

I once tried to write something using a pure TDD approach. It was enlightening.<p>Pluses were refactoring was easy and I had confidence that the system would work well at the end.<p>Minuses were it took a <i>lot</i> longer to write and I had to throw away a lot of code and tests as my understanding increased. It slowed down exploration immensely. Also, factoring the code to be completely testable led to some dubious design decisions that I wouldn&#x27;t make if I wasn&#x27;t following a pure TDD approach.<p>On balance I decided it wasn&#x27;t a generally good way to write code, although I guess there may be some circumstances it works well for.

I&#x27;m not anti-TDD necessarily but I&#x27;ve yet to see tests yield useful results at almost everyone company I&#x27;ve worked it. It could be I&#x27;ve just never worked with someone who was actually good at tests.<p>Tests in general aren&#x27;t something I regularly use and a lot of TDD feels somewhat insane to me. You can write all the tests you want ahead of time but until the rubber meet the road it&#x27;s a lot of wishful thinking in my experience. Also it makes refactoring hell since you often have to rewrite all the tests except the ones at the top level and sometimes even those if you change enough.<p>I believe tests can work, I&#x27;ve just never really seen them work well expect for very well defined sets of functionality that are core to a product. For example I worked at a company that had tests around their geofencing code. Due to backfilling data, zones being turned on&#x2F;off by time, exception zones within zones, and locations not always being super accurate, the test suite was impressive. Something like 16 different use cases it tested for (to determine if a person was in violation for a given set of locations, for a given time). However, at the same company, there was a huge push to get 80%+ code coverage. So many of our tests were brittle that we ended up shipping code regularly with broken tests because we knew they couldn&#x27;t be trusted. The tests that were less brittle often had complicated code to generate the test data and the test expectations (who tests the tests?). In my entire time at that company we very rarely (I want to say &quot;never&quot; but my memory could be wrong) had a test break that actually was pointing at a real issue, instead the test was just brittle or the function changed and someone forgot to update the test. If you have to update the test every time you touch the code it&#x27;s testing... well I don&#x27;t find that super useful, especially coupled with it never catching real bugs.<p>In a lot of TDD&#x2F;Tests in general tutorials I&#x27;ve seen they make it seem all roses and sunshine but their examples are simple and look nothing like code I&#x27;ve seen in the wild. I&#x27;d be interested in some real-world code and the tests as the evolved over time.<p>All that said, I continue to be at least interested in tests&#x2F;TDD in the hopes one day it will &quot;click&quot; for me and not see just like a huge waste of time.

TDD is great for some types of code, where the code is mostly self-contained with few external dependencies and the expected inputs and outputs are well defined and known ahead of time.<p>TDD is miserable for code that is dependent on data or external resources (especially stateful resources). In most cases, writing &quot;integration&quot; tests feels like its not worth the effort given all the code that goes into managing those external resources. Yes, I know about mocking. But mocking frameworks are: 1 - not trivial to use correctly, and 2 - often don&#x27;t implement all the functionality you may need to mock.

My feelings are far less complicated: TDD is a high-discipline approach to software development, and that&#x27;s why it doesn&#x27;t work or doesn&#x27;t get done.<p>High-discipline meaning, it entirely depends on highly competent developers (able to produce clean code, deep understanding of programming), rigorously disciplined out of pure intrinsic motivation, and even able to do this under peak pressure.<p>Which is not at all how most software is built today. Specs are shit so you gradually find out what it needs to do. Most coders are bread programmers and I don&#x27;t mean that in any insulting way. They barely get by getting anything to work. Most projects are under very high time pressure, shit needs to get delivered and as fast as possible. Code being written in such a way that it&#x27;s not really testable. We think in 2 week sprints which means anything long term is pretty much ignored.<p>In such an environment, the shortest path is taken. And since updating your tests is also something you can skip, coverage will sink. Bugs escape the test suite and the belief in the point of TDD crumbles. Like a broken window effect.<p>My point is not against TDD. It&#x27;s against ivory tower thinking that does not take into account a typical messy real world situation.<p>I&#x27;ve noticed a major shift in the last decade. We used to think like this, in TDD, in documenting things with UML, in reasoning about design patterns. It feels like we lost it all, as if it&#x27;s all totally irrelevant now. The paradigm is now hyper speed. Deliver. Fast. In any way you can.<p>This short-sighted approach leading to long term catastrophe? Not even that seems to matter anymore, as the thing you&#x27;re working on has the shelf life of fish. It seems to be business as usual to replace everything in about 3-5 years.<p>The world is really, really fast now.

I am not a TDD person, but when you write some code you want to see if it works. So you either write a unit test, or you plugin your code and do the whole song and dance to get execution to your new code.<p>I see TDD is REPL driven development for languages without a REPL. It allows you to play with your code in a tighter feed back loop, than you generally have without it.

The productivity rate went through the roof when we ditched TDD. TDD has a bit of the same problem as strict DDD. You spend a lot of time making upfront decisions about things that does not really matter or you don’t know about.<p>I see unit tests as a tool to be used where it makes sense and I use it a lot. It is true that testable code is better. Testability should be a factor when selecting tech.

It&#x27;s all about tradeoffs. I&#x27;ve done a few decades of non-TDD with a middle period of ~5 years of zealot-level commitment to TDD, and as a rule of thumb, the cost is <i>usually</i> not worth the benefit.<p>Some hidden&#x2F;unexpected side effects of TDD include the often extremely high cost of maintaining the tests once you get past the simple cases, the subtle incentive to not think too holistically about certain things, and the progression as a developer in which you naturally improve and stop writing the types of bugs that basic tests are good at catching but which you continue to write anyway (a real benefit, sure, but one that further devalues the tests). The cost of creating a test that would have caught the really &quot;interesting&quot; bugs is often exorbitant, both up front and to maintain.<p>The closest thing I&#x27;ve encountered to a reliable exception is that having e.g. a comprehensive suite of regression tests is <i>really</i> great when you are doing a total rewrite of a library or critical routine. But even that doesn&#x27;t necessarily mean that the cost of creating and maintaining that test suite was worth it, and so far every time I&#x27;ve encountered this situation, it&#x27;s always been relatively easy to amass a huge collection of real world test data, which not only exercises the code to be replaced but also provides you a high degree of confidence that the rewrite is correct.

In my opinion TDD is a good thing, but too demanding and too strict. In real life, there are very different knowledge &#x2F; experience levels in a development team and if TDD is not applied professionally, it may not help. It just needs a lot of practise and experience.<p>What it helps with a lot is improving your individual programming skills. So I recommend TDD to everyone, who never did it in practise (best case on a legacy code base) - if not to improve the code itself, then just to LEARN how it could improve your code.<p>It helped me to understand, why IoC and Dependency Injection are a thing and when to use it. Writing &quot;testable&quot; code is important, while writing real tests may be not as important, as long as you do not plan to have along running project or do a major refactoring. If you ARE planning a major refactoring, you should first write the tests to ensure you don&#x27;t break anything, though ;)<p>What I also would recommend is having a CI &#x2F; Build-Environment supporting TDD, SonarQube and CodeCoverage - not trying to establish that afterwards... Being able to switch to TDD is also a very neat way to get a nice CI setup.<p>My feeling is, that my programming and deployment skills improved best, when I did one of my personal pet projects strictly test driven with automated CI and found out about the things in TDD and CI, I really need to care about.

I got turned off from TDD in my senior year getting my CS degree.<p>During class, the teacher taught us TDD, using the Test-Code-Refactor loop. Then he wanted us to write an implementation of Conway&#x27;s Game of Life using TDD. As the students were doing it, he was doing it as well.<p>After the lesson but before the exercise, I thought &quot;This looks tedious and looks like it would make coding take far longer than necessary&quot; and just wrote the Game first, then wrote a couple dozen tests. Took me probably about 45 minutes.<p>At that point, I looked up on the projector and saw the teacher had barely done much more than having a window, a couple buttons, and some squares drawn on it, and a dozen tests making sure the window was created, buttons were created, clicking the button called the function, and that the calls to draw squares succeeded.<p>What really bothers me about &quot;true&quot; TDD (and TFA points this out), is that if you&#x27;re writing <i>bare minimum code</i> to make a unit test pass, then it will likely be incorrect. Imagine writing an abs() function, and your first test is &quot;assert (abs(-1) == 1)&quot;. So you write in your function &quot;if (i == -1) return 1&quot;. Congrats, you wrote the bare minimum code. Tadaa! TDD!

The method that works best for me is from code complete. McConnell argues (correctly, IMO) that tests are a technique, and writing tests means more code to maintain and debug. Tests can be wrong, and if the test is wrong, the code will also be wrong. Thus, a bug is introduced. He advocates first making sure you have good software design, i.e. components are laid out, how they&#x27;re going to interact with each other is well defined. So before writing any code at all, make sure you have a documented design that works conceptually.<p>Define the systems that make up your software, the classes that make up the systems, and then the functions they&#x27;ll use to talk to each other. Once it works on paper, start coding. If the design is good, the code <i>should</i> be so brain dead simple to write that a monkey could write it.<p>I find doing this I do end up with long call stacks, because each module will do something, then pass the data on like an assembly line. In each step my functions are super short and I don&#x27;t find it worth writing a test for 3 lines of code that I can tell is correct at a glance. For those few meaty functions that do more heavy logic, I will write tests for, though.

IMO, a <i>lot</i> of sage advice about TDD, well informed by years of practice, is in two Ian Cooper NDC talks, his controversial-at-the-time &quot;TDD, Where Did It All Go Wrong?&quot;[1] and, seven years later, &quot;TDD Revisited&quot;[2].<p>The blurb from the latter:<p>&gt; In this talk we will look at the key Fallacies of Test-Driven Development, such as &#x27;Developers write Unit Tests&#x27;, or &#x27;Test After is as effective as Test First&#x27; and explore a set of Principles that let us write good unit tests instead. Attendees should be able to take away a clear set of guidelines as to how they should be approaching TDD to be successful. The session is intended to be pragmatic advice on how to follow the ideas outlined in my 2013 talk &quot;TDD Where Did it All Go Wrong&quot;<p>The talks focus on reasons to avoid slavish TDD and advocate for the benefits of judiciously applying TDD&#x27;s originating principles.<p>1: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=EZ05e7EMOLM" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=EZ05e7EMOLM</a><p>2: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=vOO3hulIcsY" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=vOO3hulIcsY</a>

My feelings are quite clear, it just doesn&#x27;t work besides some simple cases without any kind of GUI (including native ones), or distributed computing algorithms.<p>It does for nice conference talks though.

The way I see, all this cultish crap: Agile, TDD, Scrum, Kanban, XP etc..etc works when essentially same thing is done nth time. I have seen plenty of <i>success</i> with these when same project is roughly repeated for many different clients.<p>It is also no surprise these terms have mostly to do with IT or related consulting and not really about engineering endeavor. In my first hand experience when I worked at engineering department there was whole lot of work done with almost non-existent buzzword bullshit. And later on with merger etc it is now an IT department so there is endless money on process training, resources, scrum masters and so on but little money is left for half decent computer setup.<p>Outside work I have seen this in my cooking, first time new dish is a hustle but in future iterations I would create little in-brain task list tickets for my own processing. Doing this in jackasstic consulting framework way would turn 1 hr worth of butter chicken recipe into 1 month work of taste feature implementation sprints.

We follow what we call TID (Test Informed Development).<p>Basically, we know that we&#x27;re going to have to write tests when we&#x27;re done, so we are sure to develop it in a way that is going to be (relatively) easy to write accurate and comprehensive tests for.

There are three things in my opinion that speak against going with TDD:<p>1. Many companies are agile, and the requirements constantly change, which makes implementing TDD even harder.<p>2. TDD does not bring enough value to justify the investment of time (for writing &amp; maintaining the test suites), the benefits are negligible, and the changes are often.<p>3. Everything is subjective [1], and there&#x27;s no reason to have such strongly held opinions about the &quot;only right way to write code&quot; when people write software in a way that is efficient for their companies.<p>[1] <a href="https:&#x2F;&#x2F;vadimkravcenko.com&#x2F;shorts&#x2F;software-development-subjective&#x2F;" rel="nofollow">https:&#x2F;&#x2F;vadimkravcenko.com&#x2F;shorts&#x2F;software-development-subje...</a>

I feel like TDD&#x27;s usefulness depends very much on what type of code you&#x27;re writing.<p>If it&#x27;s C libraries that fiddle that do lots of munging of variables, like positioning UI or fiddling with data structures... then yes, totally, it has well-defined requirements that you can assert in tests before you write it.<p>If it&#x27;s like React UI code, though, get out of here. You shouldn&#x27;t even really be writing unit tests for most of that (IMO), much less blocking on writing it first. It&#x27;ll probably change 20 times before it&#x27;s done anyway; writing the tests up from is going to just be annoying.

&gt; Testable code is best code. Only TDD gets you there.<p>I smell a circular argument but can’t quite put my finger on it.<p>&gt; If it doesn’t work for you, you’re doing it wrong<p>Ah. Start with a nigh unattainable and self-justifying moral standard, sell services to get people there, and treat any deviation as heresy. How convenient. Reminds me of Scrum evangelists. Or a cult.<p>TDD is a great tool for library-level code and in cases where the details are known upfront and stable.<p>But I can’t get it to work for exploratory work or anything directly UI related. It traps me in a local optimum and has draws my focus to the wrong places.

My beef with TDD is most every resource merely parrots the steps (red,green,..). No one teaches it well from what I have found. Nor am I convinced it’s easy to teach. I have picked up what I can by watching (what I believe) good TDD practitioners.<p>I have a feeling this is where TDD loses out the most

I find some of the <i>techniques</i> espoused by TDD proponents to be quite useful.<p>In <i>some</i> of my projects.<p>Like any technique, it&#x27;s not dogma; just another tool.<p>One of my biggest issues with &quot;pure&quot; TDD, is the requirement to have a very well-developed upfront spec; which is actually a good thing.<p><i>sometimes</i>.<p>I like to take an &quot;evolutionary&quot; approach to design and implementation[0], and &quot;pure&quot; TDD isn&#x27;t particularly helpful, here.<p>[0] <a href="https:&#x2F;&#x2F;littlegreenviper.com&#x2F;miscellany&#x2F;evolutionary-design-specification&#x2F;" rel="nofollow">https:&#x2F;&#x2F;littlegreenviper.com&#x2F;miscellany&#x2F;evolutionary-design-...</a><p>Also, I do a lot of GUI and device interface stuff. Unit tests tend to be a problem, in these types of scenarios (no, &quot;UI unit testing&quot; is not a solution I like). That&#x27;s why I often prefer test harnesses[1]. My testing code generally dwarfs my implementation code.<p>[1] <a href="https:&#x2F;&#x2F;littlegreenviper.com&#x2F;miscellany&#x2F;testing-harness-vs-unit&#x2F;" rel="nofollow">https:&#x2F;&#x2F;littlegreenviper.com&#x2F;miscellany&#x2F;testing-harness-vs-u...</a><p>Here&#x27;s a story on how I ran into an issue, early on[2].<p>[2] <a href="https:&#x2F;&#x2F;littlegreenviper.com&#x2F;miscellany&#x2F;concrete-galoshes&#x2F;#story_time" rel="nofollow">https:&#x2F;&#x2F;littlegreenviper.com&#x2F;miscellany&#x2F;concrete-galoshes&#x2F;#s...</a>

The observation about the focus on unit tests is well-made. I think it&#x27;s a crucial problem that stems from very good tools for unit testing and developers that are very familiar with these tools. It&#x27;s then very simple to discard anything that isn&#x27;t covered by these great tools.<p>But here&#x27;s an anecdote that explains why you&#x27;d always want integration tests (other anecdotes for other test paradigms probably also exist): imagine a modern subway train. That train is highly automated but, for safety reasons, still requires a driver. The train has two important safety features:<p>1. The train won&#x27;t leave a station unless the driver gives their OK. 2. The train won&#x27;t leave the station unless all doors are closed.<p>The following happened during testing: The driver gives the OK to leave the station. The train doesn&#x27;t start because a door is still open. The driver leaves the train and finds one door blocked. After the driver removes the blockage the door closes and the train departs. Now driverless.<p>I think it&#x27;s crucial to view integration tests as unit tests on a different level: You need to test services, programs, and subsystems as well as your classes, methods, or modules.

&quot;The code is the design&quot; conflicts with &quot;TDD&quot;.<p>Write code first. If that code is the v0.1 of the protocol between two blog systems great ! you can do that on a whiteboard and it looks like design when actually it&#x27;s writing code on a whiteboard.<p>Now you know what to test so write the test, after writing the code.<p>Now write the next piece of code.<p>Do not at any time let a project manager in the room

I keep wanting to be converted to TDD, but I can&#x27;t shake the feeling that I&#x27;d be writing half the code in twice the time.

I think TDD is great in the ideal, but in reality I have only worked on legacy systems where TDD was not practiced from the start. Such systems are hard to fit TDD style tests into because modifying existing code often requires large refactoring to properly inject dependencies and create seams for testing. The catch-22 is that refactoring itself is prone to breaking things without sufficient testing.<p>As a result, I often try to fit my tests into these existing systems rather than starting with the test and refactor the code under test to fit that shape. The only resource I&#x27;ve seen for dealing with this issue is the advice in the book &quot;Working Effectively with Legacy Code&quot;, to write larger system tests first so you can safely refactor the code at a lower level. Still, that&#x27;s a daunting amount of work when it&#x27;s ultimately much easier for me to just make the change and move on.

Where I come from, unit-test-driven-development tends to be a waste of resources. The interfaces will change so much during development that anything you write initially is guaranteed to be torn up. The one exception is if you&#x27;re writing an interface that crosses teams; for &quot;ship your org chart&quot; reasons, we not only can, but must assume that interface is stable enough to mock and test against (and a knife-fight is necessary if it isn&#x27;t).<p>However, getting the client to agree that their design feature is satisfied by a specific set of steps, then writing software that satisfies that request, <i>is</i> a form of test-driven-development and I support it.

To me, it really depends:<p>1. Writing frontend code -- I&#x27;ve left testing all together. I&#x27;d never hope to keep up with the pace<p>2, Writing APIs -- rudimentary testing that at least catches when I introduce regressions<p>3. Writing smart contracts -- magnitudes more test than actual code.

Trouble with TDD is that it doesn&#x27;t fit product development.<p>1. TDD isn&#x27;t faster than simply writing test cases down, and executing them manually, especially when UI is involved.<p>2. TDD quadruples the amount of work needed for any given change.<p>3. TDD is the opposite of agile where you try to ship some product to the user ASAP to get feedback before spending time to refactor and clear technical debt. Write tests only for features that are confirmed so you don&#x27;t spend time and effort on stuff people don&#x27;t want.<p>4. Similar point as 1, but you need to evaluate if making something easy to test is worth the time savings than just running the test manually.

There&#x27;s a lot of conflating unit-testing&#x2F;TDD and QA here.<p>Yes, when you start writing code, it may not be well defined, or you (the coder) may not understand the requirement as intended. That&#x27;s OK.<p>Write your test. Make clear your assumptions and write the code against that. Now your code is easier to refactor and acts as living documentation of how you understood the requirement. It also acts to help other engineers not break your code when they &quot;improve&quot; it.<p>If QA, the client or God himself decides the code needs to change later, for whatever reason, well that&#x27;s OK too.

I think a lot of distinct, but interrelated topics are being brought up here:<p>* Using tests as a (or even the primary) design tool (strong TDD)<p>* Test-first development (weak TDD)<p>* Integration vs. unit testing<p>* What is a unit test?<p>* Should one use mocks and if so, when and how?<p>I think each of these topics merits a separate discussion and you can be e.g. in favour of at least weak TDD while maintaining that unit tests have little value, or you can be in favour of unit tests but disagree that &quot;unit test&quot; means &quot;unit = class&#x2F;method&#x2F;function&quot;. You can have differing opinions on the value of mocks even if you subscribe to strong TDD (that&#x27;s essentially the classicist vs. mockist divide in the TDD scene - for example, Bob Martin is more skeptical of mocking than, say, the &quot;Growing Object-Oriented Software, Guided by Tests&quot; crowd is).<p>IMHO, the biggest problem with testing is that most developers are not very good at it. I routinely see tests that are so complicated that it becomes very hard to understand, let alone debug them. In my experience, a lot of people also skip tests when reviewing code.<p>Well-written tests make a code base a joy to work with. Bad tests make everything painful. I don&#x27;t know how to fix this, but we should pay more attention to it. If we had better tests, it would be easier to argue about the merits of TDD, unit testing, mocking etc. With badly written tests, everything devolves into a &quot;why even test [this specific thing]?&quot; kind of discussion.

I don&#x27;t have complicated feelings towards TDD at all.<p>It has a good idea but as many others have said, you need a pretty well spec&#x27;ed software beforehand for it to work. When you code a certain piece you might change it, top to bottom, several times -- we aren&#x27;t perfectly thinking machines and we need to iterate. Having to re-prototype tests every time hurts productivity not only in terms of hours -- an obstacle that can be overcame in a positive environment and is rarely a true problem. It hurts in terms of it demotivating you and you losing the creative energy you wanted to devote to solving the problem.<p>The &quot;it depends&quot; thing will always be true. When you gather enough experience you will intuitively know the right approach to prototyping + testing an idea.<p>TDD is but one tool in a huge toolbox. Don&#x27;t become religious over it.<p>I liked part of Kent Beck&#x27;s writings back in the day but I am inclined to agree with other posters that he mostly wrote books to sell courses. I mean the book had good content, don&#x27;t get me wrong, but they also didn&#x27;t teach you much except &quot;don&#x27;t do waterfall&quot;.<p>Martin Fowler also wrote some gems, especially &quot;Refactoring&quot;, but in the end he too just tried to enrich your toolbox -- for which I am grateful.<p>Ultimately, do just that: enrich your toolbox. Don&#x27;t over-fixate on one solution. There is not one universal solution, at least we don&#x27;t know it yet. Probably one day a mix of mathematical notation + a programming language will converge into one and we won&#x27;t ever need another notation again but sadly none of us will live to see it.

I had no idea that people were quite so religious about this sort of thing.<p>It’s pretty clear at this point that testing is one of the most valuable tools in the box for getting sufficiently “correct” software in most domains.<p>But it’s only one tool. Some people would call property checkers like Hypothesis or QuickCheck “testing”, some people wouldn’t. Either way they are awesome.<p>Formal methods are also known to be critical in extreme low-defect settings, and seem to be gaining ground more generally, which is a good thing. Richer and richer type systems are going mainstream with like Rust and other things heavily influenced by Haskell and Idris et al.<p>And then there’s good old: “shipping is a feature, and sometimes a more important feature than a low defect count”. This is also true in some settings. jwz talk very compellingly about this.<p>I think it’s fine to be religious about certain kinds of correctness-preserving, defect-preventing processes in <i>domains that call for an extreme posture on defects</i>. Maybe you work on avionics software or something.<p>But in general? This “Minimal test case! Red light! Green light! Cast out the unbelievers!” is woo-woo stuff. I had no idea people took this shit seriously.

I write tests in order to have something to run and hit breakpoints on while I develop code. Is that TDD? The tests don&#x27;t even necessarily check anything at the earliest stages, obviously they are red if the code barfs but that&#x27;s about it. Once the code solidifies I may take some output and persist it to make sure it doesn&#x27;t change, but &quot;does not crash&quot; is technically a testable endpoint!

TDD helps facilitates the process of building up of confidence in the product. However, the value it adds is contextual in the sense that if a product is not well defined and at a certain point of maturity then it may not be helpful to shift gears and adopt TDD.<p>But fundamentally no one should ever be trying to merge code that hasn’t been unit tested. If they are, that is a huge problem because it shows arrogance, ignorance, willingness to kick-the-can-down-the-road, etc.<p>From an engineering perspective the problem is simple: if you’re not willing to test your solution then you have failed to demonstrate that you understand the problem.<p>If you’re willing to subsidize poor engineering then you’re going to have to come to terms with adopting TDD eventually, at some stage of the project’s lifecycle, because, you have created an environment where people have merged untested code and you have no way to guarantee to stakeholders that you’re not blowing smoke. More importantly, your users care. Because your users are trusting you. And you should care most of all about your users. They are the ones paying your bills. Be good to them.

What is frustrating is TDD evangelists insisting everyone do purist TDD in their regular development (like the guy being quoted in this article).<p>You set your standards as a team of what you will consider acceptable tests and as long as the dev submitting the PR meets that standard why does it matter if they did TDD or not? TDD is a means to end, it&#x27;s not a religion. As long as you write tests that meet the standard it doesn&#x27;t matter when you write those tests.<p>The level of micromanaging that TDD evangelists seem to want in people&#x27;s workflows is infuriating. It&#x27;s literally cultish.<p>Edit: I realize this came across more negative and abrasive than I intended. I think TDD has some good parts (primarily around gamification of writing tests and giving a serotonin hit whenever a test goes from red to green). I practice TDD around 50% of the time when appropriate, but most people who have worked in the industry that TDD as sold by purists is impractical and adds negative value.

The TDD tradition comes from dynamically typed languages. If you write a Ruby or JavaScript function it&#x27;s got a good chance of not working the first time you run it. However, with statically typed languages your function has a much better chance of running, if it compiles. IMO TDD only makes sense for dynamically typed languages.

I think TDD shines in combination with a layered architecture, the combination of both increases “changeability” of the project. Layered architecture and DI makes easy and possible to test any layer. And the test become a live documentation of how to use the code you have written.<p>Refactoring becomes then easy although sometimes tedious, but provides a degree of confidence that your change works with all posible ways to use the code.<p>Its also healthy to break the rules if time pressure, but keeping a registry of technical debt, helps keeping the morale up. There is nothing more demoralizing that working on an environment where you can’t estimate because who knows what will be broken, it’s hard to make improvements because everything is entangled, and there is no time to invest in a rewrite. This usually ends up with very talent people quitting if they are unable to fix it.

I always liked the discussion &quot;Is TDD dead&quot; between David Heinemeier Hansson (of Ruby on Rails and Basecamp fame) and Kent Beck. DHH arguing against, Kent Beck obviously in favor of TDD. Martin Fowler is moderator and the discussion is very nuanced and slowly identifies areas where TDD has its benefits and where it should be rather avoided. <a href="https:&#x2F;&#x2F;martinfowler.com&#x2F;articles&#x2F;is-tdd-dead&#x2F;" rel="nofollow">https:&#x2F;&#x2F;martinfowler.com&#x2F;articles&#x2F;is-tdd-dead&#x2F;</a>

Why does TDD exist?<p>1. We want a useful target for our software. You could design a graphical mock-up of software and design your software to fit it. Or you could create a diagram (or several). Or you could create a piece of software (a test) which explains how the software is supposed to work and demonstrates it.<p>2. When we modify software over time, the software eventually has regressions, bugs, design changes, etc. These problems are natural and unavoidable. If we write tests before merging code, we catch these problems quickly and early. Catching problems early reduces cost and time and increases quality. (This concept has been studied thoroughly, is at the root of practices such as Toyota Production System, and is now called <i>Shift Left</i>)<p>3. It&#x27;s easy to over-design something, and hard to design it &quot;only as much as needed&quot;. By writing a simple test, and then writing only enough code to pass the test, we can force ourselves to write simpler code in smaller deliverable units. This helps deliver value quicker by only providing what is needed and no more.<p>4. Other reasons that are &quot;in the weeds&quot; of software design, and can be carefully avoided or left alone if desired. Depends on if you&#x27;re building a bicycle, a car, or a spaceship. :-)<p>But as in all things, the devil&#x27;s in the details. It&#x27;s easy to run into problems following this method. It&#x27;s also easy to run into problems <i>not</i> following this method. If you use it, you will probably screw up for a while, until you find your own way of making it work. You shouldn&#x27;t use it for everything, and you should use good judgement in how to do it.<p>This is an example of software being more craft than science. Not every craftsperson develops the same object with the same methods, and that&#x27;s fine. Just because you use ceramic to make a mug, and another person uses glass, doesn&#x27;t mean one or the other method is bad. And you can even make something <i>with both</i>. Try to keep an open mind; even if you don&#x27;t find them productive, others do.

Testing is very important. Ok.<p>The problem I have with TDD is the concept of writing tests first. Tests are not specifications (in TDD world the line is blurred.) Tests are confirmation.<p>I develop my code (I write back end plumbing code for iOS currently) from a test frame work.<p>My flow:<p>* Specify. A weak and short specification. putting too much work into the specification is a waste. &quot;The Gizmo record must be imported and decoded from the WHIZZBAZ encoding into a Gizmo object&quot; is plenty of specification.<p>* Write code for the basic function.<p>* Write a test for validity of the code (the validity of the record once loaded in the Gizmo&#x2F;WHIZBAZ case)<p>But the most important tests are small micro tests (usually asserts) before and after every major section (a tight loop, a network operation, system calls etcetera). More than half my code is that sort of test.

The &#x27;T&#x27; in TDD stands for design. :) The name of it has always hurt the concept I think.<p>In my experience TDD uptake and understanding suffers because a lot of developers are in a context of using an existing framework, and that framework sort of fights against the TDD concepts sometimes. Getting around that with things like dependency injections, reversals etc then gets into the weeds and all sorts of &#x27;Why am I doing this&#x27; pain.<p>Put another way, a lot of commercial development isn&#x27;t the nice green-field coding katas freedom, it&#x27;s spelunking through &#x27;Why did ActiveRecord give me that?&#x27; or &#x27;Why isn&#x27;t the DOM refreshing now?&#x27;. Any friction then gets interpreted as something wrong about TDD and the flow gets stopped.

There are quantitative studies showing that TDD has little to no impact development time or code quality[0]. What has been found, however, is that writing code in short increments helps a lot (something that can be caused by using TDD).<p>For more information on studies covering the topic (and much more), I highly recommend watching Greg Wilson&#x27;s Software Engineering&#x27;s Greatest Hits[1].<p>[0]: <a href="https:&#x2F;&#x2F;neverworkintheory.org&#x2F;2016&#x2F;10&#x2F;05&#x2F;test-driven-development.html" rel="nofollow">https:&#x2F;&#x2F;neverworkintheory.org&#x2F;2016&#x2F;10&#x2F;05&#x2F;test-driven-develop...</a> [1]: <a href="https:&#x2F;&#x2F;youtu.be&#x2F;HrVtA-ue-x0?t=448" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;HrVtA-ue-x0?t=448</a>

This is a good article, with (for me anyway) quite a twist at the end.<p>The author quotes a tweet expressing amazement that any company might not use TDD, 20 years after it was first popularised - and then writes<p>&quot;I’d equate it to shell scripting. I spent a lot of time this spring learning shell scripting&quot;<p>Wow! I feel like the person in the tweet. It&#x27;s amazing to me that someone could be in a position to write an article with such solid development background without having had shell scripting in their everyday toolbox.<p>(I use TDD some of the time - I was slow to pick it up and a lot of my older code would have been much better if I had appreciated it back then. I like it very much when I don&#x27;t really know how the algorithm is going to work yet, or what a good API looks like.)

Is dogma really useful? No matter how sensible some strategy is, can we afford to treat it as an absolute truth?<p>I get the feeling that we are all inclined to think that we have the entire story of development in our own personal heads and can therefore lay down laws.<p>...and yet most of these disciplines need everyone&#x27;s co-operation and one can feel that if you don&#x27;t treat it as dogma then you&#x27;re never going to make everyone &quot;comply&quot;...<p>I think the fact that TDD (and other popularly debated methodologies) haven&#x27;t taken over just by being obviously easier and better is a sign that they aren&#x27;t really suitable for being made into dogmas. They&#x27;re tools and we should have the choice like any workman to choose them or not.

TDD is another tool in the toolbox. It has it&#x27;s place, and combined with good tooling, can make for a great development experience. I use it mostly when adding features to an existing code base. In C#, with modern tooling like Visual Studio, Rider, or ReSharper, you can use your test as a base to start scaffolding methods out with auto generated code, and that can end up being a time saver.<p>For a brand new product, I&#x27;m almost never using TDD. I&#x27;m building out a solution in the pattern I want, getting some minimal feature or features up, and then I write tests appropriate to that pattern. Later on I might use TDD to keep working on it, but it can be a burden at the start of projects.

Working on API, Services and a lot of automation. At some point I got really into the habbit of TDD. Now I just can&#x27;t go without it anymore. When I am thinking of a feature, I am always thinking of the test first. It has gotten to the point where it feels like I am walking around naked when I write test-less code&#x2F;features. It&#x27;s not just that I have gotten used to it, because whenever I coded myself into a corner, without tests, it seemed like the answer was having tests first. At least, it would have caught a lot of the issues I would have run into later.<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=iwUR0kOVNs8" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=iwUR0kOVNs8</a>

Me too but let’s play devils advocate here.<p>1) you likely aren’t going to get the job without some absurd degree of unit testing<p>2) most of your code should be pure functions making them trivial to unit test<p>3) writing pure functions and making your code testable makes your system less coupled which is a good thing<p>4) designing the tests is designing the software which is often helpful<p>That’s it I don’t have a fifth point. Actually I do, writing software is a form of art and it cannot be summed up as simply as unit testing everything always bad or always good. There might be somethings like converting an engine performance simulation to Golang from Excel that might be fantastic to unit test the shit out of, testing if onPress works on your button component is basically pointless.

The first time I encounter TDD, I was a bit surprised because it encourages you to write tests (client code) first. Well, I started my professional career without knowing about TDD, but I did know that usually it&#x27;s best to start writing the client code first. E.g., you write your main.c&#x2F;Main.java&#x2F;main.go first, referencing classes&#x2F;code that do not exist yet, and wiring everything together. Then you move on to the next layer, write code that should exist but still relying on future code that doesn&#x27;t exist yet. Eventually you end up writing the whole thing. Sometimes the other approach works equally well (e.g., starting from the small blocks and going up).

TDD&#x27;s contribution to software quality scrapes the bottom of the barrel. Attention to detail in scalable design, formal verification, fuzzing, and mutation testing offer deeper guarantees of successful operation. But of course, the American ideal &quot;make money&quot; is worn proudly on the rim of management noses. It&#x27;s the wrong prescription, but they&#x27;re too busy counting their bills to care. This is evident especially in cybersecurity, where the posture amounts to silent prayer that no one stumbles across their JRE 1.0&#x27;s and their Windows XP&#x27;s and Google&#x27;s latest attempt at a programming language with buffer overflows by design--batteries included.

I think TDD is just busywork in another form. Managers seem to like to keep people busy, often just to watch them work and feel power or something from it. They might have a really good dev on the team who can smash everything in front of them super quickly and they can&#x27;t keep them busy enough to get their power trip on, so they add a boat anchor and tell the dev to drag that around while they work. Instant slowdown in productivity, dev takes 3X as long, manager is loving it. I think that&#x27;s also why you find this junk in megacorps where there is little actual work and everyone is politicking all day. Lotta power trippers in those companies.

I never really understood how TDD can make software better, except for one thing: it forces people to write tests. But that&#x27;s just a discipline thing: tests are boring and development is fun, you have to deserve your fun by doing the boring part first.<p>It also makes cutting corners more difficult, because it is possible to have (sort of) working software without testing, but you can&#x27;t have working software if the only thing you have are failing tests (the important first step in TDD). Most TDD people probably thing of that as a positive, I don&#x27;t. Sometimes, cutting corners is the right thing to do, sometimes, you actually need to write the code to see if it is viable, and if it is not, well, you wasted both the tests and the code, not just the code.<p>But I don&#x27;t think it is the only problem with TDD. The main problem, I think, is right there in the name &quot;test driven&quot;. With a few exceptions, tests shouldn&#x27;t drive development, the user needs should. Test driven development essentially means: write tests based on the users need, and then write code based on the tests. It means that if your tests are wrong and your code passes the tests, the code will be wrong, 100% chance, and you won&#x27;t notice because by focusing on the tests, you lost track of the user needs. It is an extra level of indirection, and things get lost in translation.<p>Another issue I have noticed personally: it can make you write code no one understands, not even yourself. For example, your function is supposed to returned a number, but after testing, you notice that are always off by +1, the solution: easy, subtract 1 to the final value. Why? dunno, it passes the tests, it may even work, but no one understands, and it may bite you later. Should I work like that? Of course not, but this is a behavior that is encouraged by the rapid feedback loop that TDD permits. I speak from experience, I wrote some of my worst code using that method.<p>If you want an analogy of why I am not a fan of TDD: if you are a teacher and give your students the test answers before you start your lesson, most will probably just study the test and not the lesson, and as a consequence they will most likely end up with good grades but poor understanding of the subject.

One thing that I have observed is, there is often a problem dependent sweet spot for the integration level of a test suite. Sometimes that is literally testing the behaviors of every method while other times it can be end-to-end testing or somewhere in-between. The challenge is, it can take a great deal of thought to arrive at the appropriate inflection points. One approach I take is to try to think about what suite of tests would make it easier for a developer who is new to the code base to be productive in it. They should feel that the test suite is helping them, not holding them back.

IMO TDD should be by opportunity and not policy. That solves basically all the problems I have with it.<p>TDD is great because it forces you to concretize and challenge assumptions, and provides a library of examples for new devs to a codebase.

I don&#x27;t understand where&#x2F;how in TDD you are allowed to switch from concrete &quot;base case&quot; tests to tests which probe the inductive hypothesis.<p>It seems that TDD can forever evade actually solving a problem in its general form, always just extending the number of concrete cases that work.<p>For instance, a function to measure the length of a string first works only for the case len(&quot;&quot;) == 0; the result is wrong for all else. TDD allows this to be extended into &quot;working&quot; in idiotic steps like len(&quot;a&quot;) == 1, but len(&quot;b&quot;) returns 0, and so on.<p>Also, how, in TDD, can we write a test which says &quot;for any input not handled by the tests developed so far, I want an exception&quot;. That is to say, when I write the first test len(&quot;&quot;) == 0 and get it to pass, I don&#x27;t want len(&quot;a&quot;) to return 0; I want it to throw. I could write a test for that: throws(len(&quot;a&quot;)), and it would initially fail. But I want the behavior to be entirely general, and I don&#x27;t want to maintain the test when len(&quot;a&quot;) changes to returning 1.<p>These problems make TDD just look like a way to get useful work out of complete morons, in problem areas involving calculating functions that have finite domains that can be exhaustively tested.<p>As soon as you write a code that is more general: which makes more than the new test case to pass, you&#x27;re leaving TDD. For instance, the test case wants len(&quot;a&quot;) == 1, but you write code such that len(&quot;b&quot;) == 1 would also pass, and len(&quot;abc&quot;) == 3 would also pass and so on. You now have a lot of useful and good behavior that is not tested. You&#x27;ve not had a len(&quot;abc&quot;) == 3 which went from red to green.<p>Once other code starts relying on len being a reliable length function, you must have left TDD behind. Code is calling len(&quot;foo.txt&quot;), which has not been tested! How realistic is to prevent that?<p>At some point, a supposedly TDD-developed program must handle real-world inputs, and they could not all have been tested, because that&#x27;s the reality. Only simple functions with small finite input spaces can be exhaustively tested. TDD must necessarily allow a lack of testing to creep in, and the rules for that, if any, are <i>ad hoc</i>.

I&#x27;ve chosen to interpret TDD as &quot;test driven design&quot;, based on the idea that systems designed to be easily unit-testable tend to also be easier to understand, maintain, extend, compose, repurpose, refactor, etc.<p>I deviate from some proponents in that I think this kind of TDD can be done while writing zero unit tests, but in practice they keep you sensitized to good design techniques. Plus the tests do occasionally catch bugs, and are otherwise a good forum to exercise your types and illustrate your code in action.

What I do is not really pure TDD. I usually don&#x27;t have a very clear specification of what system needs to be doing (as it is an iterative process). So I write the code and then write tests to see if it gives required outputs for given inputs. Then I write tests to see if it behaves correctly under edge cases. I also pretty much stopped using debuggers because of that. Simply there is no need. I can reproduce an error using the test and then fix the code until it passes it.

I don&#x27;t want to write tests, why? Because most of them are like x = 1; if x != 1 panic(); If you don&#x27;t trust the language, why do you use it?<p>But then there are tests that make sense but are hard to write.<p>And then there are tests that require infrastucture.<p>I don&#x27;t write tests for every little thing. But I do write them if I actually do want to test the functionality of what I just wrote. But stuff like<p><pre><code> s := new (Service) if s == nil { t.Fail() } </code></pre> is completely unnecessary

My advice is to follow the famous quote “given enough eyeballs all bugs are shallow”. Add a “send feedback” link in your application and let your users quickly and easily notify you when something goes wrong. My product has several million users and has zero tests and when bugs get pushed to production, users tell me in seconds. Sometimes pushing bugs to production is part of my workflow and then quickly fixing them allows me to iterate at record speeds.

I think people sometimes forget that tests are made of code too. If it&#x27;s possible to write bad code, it&#x27;s certainly possible to write bad tests. And writing bad tests first (as in `test-driven`) won&#x27;t make them any better. At some point, people see bad tests _and_ bad code together and instead of blaming it on the &quot;bad&quot; part, they blame it either on the tests, or on the fact that the tests were written first.

It seems to me that I began hearing a lot about TDD during an era of abundant web development work in the early 2010s. I think that kind of work lends itself well to TDD since there are a lot of well established design principles and conventions in that space. But it doesn&#x27;t work as well in other more general software design contexts that are more open ended.

TDD is a great example of where major differences between businesses and departments has direct impact on your software engineering.<p>When business people don&#x27;t know what they want, do not try TDD. It will be a waste of time. When people do KNOW, or you have a RELIABLE subject matter expert (at a big company you might have one of these), TDD is a lot safer and easier to do.

My reluctance to do pure &quot;red-green-refactor&quot; is more a side-effect of the IDE than the testing philosophy.<p>Maybe it&#x27;s an OCD thing, but I don&#x27;t like seeing compiler errors of unimplemented pseudo-code and mock placeholders. It breaks my flow.<p>But 2 files open at all times, writing tests as the main class is being developed? And no compiler errors? Love it.

&gt; ... I practice “weak TDD”, which just means “writing tests before code, in short feedback cycles”. This is sometimes derogatively referred to as “test-first”. Strong TDD follows a much stricter “red-green-refactor” cycle:<p>&gt; 1. Write a minimal failing test.<p>&gt; 2. Write the minimum code possible to pass the test.<p>&gt; 3. Refactor everything without introducing new behavior.<p>&gt; The emphasis is on minimality. In its purest form we have Kent Beck’s test &amp;&amp; commit || reset (TCR): if the minimal code doesn’t pass, erase all changes and start over.<p>An example would be helpful here. In fact, there&#x27;s only a single example in the entire article. That&#x27;s part of the problem with TDD and criticisms of it. General discussions leave too much to the imagination and biases from past experience.<p>Give me an example (pick any language - it doesn&#x27;t matter), and now we can talk about something interesting. You have a much better chance of changing my mind and I have a much better chance of changing yours.<p>The example in the article (quick sort) is interesting, but it&#x27;s not clear how it would apply to different kinds of functions. The author uses &quot;property testing&quot; to assert that a sorted list&#x27;s members are of ascending value. The author contrasts this with the alleged TDD approach of picking specific lists with specific features. It&#x27;s not clear how this approach would translate to a different kind of function (say, a boolean result). Nor is it clear what the actual difference is because in both cases specific lists are being chosen.

As with anything, there&#x27;s going to be a group of strict adherents, strong opposition and the set of people who have used it enough to only apply it where useful.<p>It&#x27;s definitely useful, but those strongly opposed often won&#x27;t use it at all unless it mandated which tends to lead to strict adherence policies at a lot of companies.

One thing with TDD is that the code you are writing, you know, is testable. It’s also easy testable code, as it’s already written in such way. Code which isn’t written with TDD may be testable but more often than not it’s hard to test it. And code that’s hard to test will not be tested. And that’s a slippery slope.

I feel like I&#x27;ve never seen a project that I liked, where I surprisingly discovered it was developed using TDD.<p>I have seen only a handful of projects, show as examples of TDD, that actually were projects I liked.<p>Its a variation of the &quot;don&#x27;t worry they&#x27;ll tell you&quot; joke. How do you know a project was TDD?

&gt; You write more tests. If writing a test “gates” writing code, you have to do it. If you can write tests later, you can keep putting it off and never get around to it. This, IMO, is the principle benefit of teaching TDD to early-stage programmers.<p>Early stage programmers and all stages of project manager.

It&#x27;s odd how much time software engineers will spend on discussing the same old boring stuff like TDD. There are a thousand flowers blooming in cryptography, ML&#x2F;AI, cryptocurrencies etc. Yet here we are with yet another rehash of the same discussion

Write the code you wish you had. Define your expectation. Does your coding ability keep up with your expectations? Does that continue to hold for you or anyone else on your team on your worst day?<p>Don&#x27;t have any expectations and are exploring? Don&#x27;t do any of this.

I believe a good way of programming is to always reverse program. So you start with the output and work back to where the algorithm or program starts. In that way you can easily extract an unit test after you finished your task.

Some people do tests, some people do development, and some people do test driven development.<p>If you are picking up some code to work on, the nicest to work with is the one that was done with TDD.

I laugh every time I see someone trying to push TDD as the one way to write software. If it is useful to you.. then go ahead. Don&#x27;t try push it on everyone.

Slightly off topic, but I find the author&#x27;s attempt to use an iterative method (TDD) to derive a recursive algorithm (quicksort) somewhat comical

I generally expect to see decent tests along with code in the same PR. I don&#x27;t care whether the tests were written before or after the code.

I noticed that proponents of TDD are mostly consultants who sell TDD courses or seminars.<p>You rarely see someone who writes production code preach TDD.<p>Something fishy there...

I don’t. Never once seen TDD help more than it was a time sink. On the other hand writing lots of tests is great, but no need for TDD.

TDD doesn’t work for the really interesting problems: you can’t achieve a deep creative solution through small mechanical improvements

I&#x27;ve been in software development for over twenty years.<p>I have similar feelings about maximalism in a lot of areas.<p>Many organizations producing software today don&#x27;t share many values with me as an engineer. Startups aren&#x27;t going to value correctness, reliability, and performance nearly as much as an established hardware company. A startup is stumbling around trying to find a niche in a market to exploit. They will value time to market above most anything else: quick, fast solutions with minimal effort. Almost all code written in this context is going to be sloppy balls of mud. The goal of the organization is to cash out as fast as possible; the code only has to be sufficient to find product-market fit and everyone riding the coat-tails of this effort will tolerate a huge number of software errors, performance issues, etc.<p>In my experience practicing TDD in the context of a startup is a coping mechanism to keep the ball of mud going long enough that we don&#x27;t drown in errors and defects. It&#x27;s the least amount of effort to maintain machine-checked specifications that our software does what we think it does. It&#x27;s not great. In other contexts it&#x27;s not even sufficient. But it&#x27;s often the only form of verification you can get away with.<p>Often startups will combine testing strategies and that&#x27;s usually, &quot;good enough.&quot; This tends to result in the testing pyramid some might be familiar with: many unit tests at the bottom, a good amount of integration tests in the middle, and some end-to-end tests and acceptance tests at the top.<p>However the problem with TDD is that I often find it insufficient. As the article alludes to there are plenty of cases where property based testing has stronger guarantees towards correctness and can prevent a great deal more errors by stating properties about our software that must be true in order for our system to be correct: queued items must always be ordered appropriately, state must be fully re-entrant, algorithms must be lock-free: these things are extremely hard to prove with examples: you need property tests at a minimum.<p>The difficulty with this is that the skills used to think about <i>correctness</i>, <i>reliability</i>, and <i>performance</i> require a certain level of mathematical sophistication that is not introduced into most commercial&#x2F;industrial programming pedagogy. Teaching programmers how to think about what it would mean to specify that a program is correct is a broad and deep topic that isn&#x27;t very popular. Most people are satisfied with &quot;works for me.&quot;<p>In the end I tend to agree that it takes a portfolio of techniques and the wisdom to see the context you&#x27;re working in to choose the appropriate techniques that are sufficient for your goals. If you&#x27;re working at a startup where the consequences are pretty low it&#x27;s unlikely you&#x27;re going to be using proof repair techniques. However if you&#x27;re working at a security company and are providing a verified computing base: this will be your bread-and-butter. Unit tests alone would be insufficient.

Meh. OP sets of a strawman that rarely exists outside Reddit message boards.<p>TDD is the wind, it cannot be captured by your net.

It looks like the human brain is wired up in a way that can turn anything into a religion

TDD is just a huge ugly kluge to compensate for languages designed with inadequate internal correctness guarantees. So instead we have to tack on a huge infrastructure of external correctness guarantees instead. TDD is an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a strong type system.

damn it. hoped it&#x27;s about that train game

TDD - test driven development

Seems like the TLDR is: Well-intentioned patterns break down when taken maximally.

The author defines two types of TDD: &quot;weak TDD&quot; and &quot;strong TDD&quot;. I&#x27;d argue there&#x27;s another, though I&#x27;m not sure what to call it -- &quot;Pragmatic TDD&quot; perhaps? What I care about is having unit tests that cover the complicated situations that cause bugs. I think one of the main problems with TDD is its proponents focus so much on the process as opposed to the end result.<p>The way I practice &quot;pragmatic TDD&quot; is to construct my code in a way that allows it to be tested. I use dependency injection. I prefer small, static methods when possible. I try not to add interfaces unless actually needed, and I also try to avoid requiring mocks in my unit tests (because I find those tests harder to write, understand, and maintain).<p>Notably: I explicitly don&#x27;t test &quot;glue code&quot;. This includes stuff in startup -- initializing DI and wiring up config -- and things like MVC controllers. That code just doesn&#x27;t have the cost-benefit to writing tests: it&#x27;s often insanely difficult to test (requiring lots of mocks or way over-complicated design) and it&#x27;s obvious when broken as the app just won&#x27;t work at all. Integration or UI automation tests are a better way to check this if you want to automate it.<p>I strive to just test algorithm code. Stuff with math, if&#x2F;else logic, and parsing. I typically write the code and tests in parallel. Sometimes I start writing what I think is a simple glue method before realizing it has logic, so I&#x27;ll refactor it to be easy to test: move the logic out to its own method, make it static with a couple extra parameters (rather than accessing instance properties), move it to its own class, etc.<p>Sometimes I write tests first, sometimes last, but most often I write a few lines of code before I write the first tests. As I continue writing the code I think up a new edge case and go add it as a test, and then usually that triggers me to think of a dozen more variations which I add even if I don&#x27;t implement them immediately. I try not to have broken commits though, so I&#x27;ll sometimes comment out the broken ones with a `TODO`, or interactive rebase my branch and squash some stuff together. By the time anyone sees my PR everything is passing.<p>I think the important thing is: if you look at my PR you can&#x27;t tell what TDD method I used. All you see is I have a bunch of code that is (hopefully) easy to understand and has a <i>lot</i> of unit tests. If you want to argue some (non-tested) code I added should have tests, I&#x27;m happy to discuss and&#x2F;or add tests, but your argument had better be stronger than &quot;to get our code coverage metric higher&quot;.<p>Whether I did &quot;strong red-green-refactor TDD&quot; or &quot;weak TDD&quot; or &quot;pragmatic TDD&quot; the result is the same. I&#x27;d argue caring about <i>how</i> I got there is as relevant as caring about what model of keyboard I used to type it.

TDD is really, really bad. I won&#x27;t even add arguments. TDD is typically sold by Agilists from which most content deserves to go in the same trash bin. Most of these people have never written code for real. Their opinions are worthless. Thanks, bye.