13 ms·

I'd be curious to hear what kovarex thinks in 2-3 months. TDD is often sold as a fix-all solution, which is incredibly appealing to mgmt and quite fun for most

• ashtonkem 5y ago
  Red/Green is a good technique for fixing bugs and extending existing functionality.
  • koonsolo 5y ago
    What is the chance of a fixed bug getting broken again? As it turned out in our analytics over 10 years: very very low. So the effort you put into writing a test for a bug, has most likely a negative return on investment. That time could be better spend somewhere else.
    • RHSeeger 5y ago
      You're ignoring various parts of the equation, though. - Writing a test for a bug is part of understanding the bug, much like rubber ducking, it helps you make sure you know exactly what causes the bug. - The better you are at writing tests, the less time it takes you to do so. - Having tests for the code means the code is testable. In general (but not always), code being testable means it's better code (more readable, less complex, etc). - Having tests for code means you have to worry less about breaking it when making changes. This allows work to proceed faster. So it's not just "did adding this test prevent this one bug from re-occurring", it's "did adding tests improve our development overall". The later is far more likely to be true than the former.
    • duncan-donuts 5y ago
      Maybe for you and your org though. This isn’t universal. I’ve worked somewhere that would use the phrase “whack-a-mole bugs” because teams would start thrashing and break each others’ shit over and over. There’s a ton of stuff we could have done — communicate (even just a tiny bit), less silos, communicate!, write better code, write tests. When your problems are much more fundamental, like teams just flat out don’t talk, writing the test is an easier investment.
    • synthc 5y ago
      I disagree: when fixing a bug I usually start with writing a failing test that reproduces and exposes the problem, and then fix the problem so that the test passes. Understanding, reproducing and fixing the problem is the hard part, once that is done making a test out it hardly takes any time. Writing the test does not only prevent regressions, it also helps with confirming you actually fixed the bug.
• koonsolo 5y ago
  The thing is that all that extra test code also needs to be maintained, also contains bugs, etc. It all comes down to return on investment. For example, I used to agree with TDD that for every bug, first write a test that fails, and then fix the bug. That way you prevent regression. So I proposed this to my manager, and he responded: we tracked all bugs in our system for the last 10 years, and when you look at fixed bugs that get broken again, it only occured very rarely. So in the end, doing that was not the best investment of effort.
  • asddubs 5y ago
    One point uncle bob makes is that doing this for everything allows you to make far-reaching architectural changes with confidence that you haven't broken a bunch of things in places you don't even realize. so the tests are a tool to allow you to do refactorings you would otherwise be scared of
    • koonsolo 5y ago
      That is definitely true and I fully agree with this. The benefit is basically all the tests that you don't have to change and give you confidence that your refactorings don't break certain things. But the drawback is all those tests that do need to be rewritten because of the refactoring, and so will slow you down again. But in the end for this use-case, I think it's a good ROI. Probably the best use-case for TDD.
      • tarcon 5y ago
        Thats a problem of your tests. Go the classicist approach and your test don't fail after a significant refactoring.
      • buzzwordninja 5y ago
        A brittle test suite during refactoring is usually caused by too much mocking. Look at the concept of sociable tests. https://martinfowler.com/bliki/UnitTest.html https://martinfowler.com/bliki/UnitTest.html
    • 5y ago
• alanfranz 5y ago
  My 2c: tdd is great in order to learn to create testable designs. You can’t tdd nontestable code. Once you understand how to design testable code, tdd offers minimal benefits. The real value comes from thorough, automated testing suites, whatever their origin is.
  • ashtonkem 5y ago
    Good observability standards and fast releases catch more bugs than meticulously maintained test suites, imho.
    • drenei 5y ago
      I actually think if you squint testing is part of observability, except it gives you signal during the development phase. And observability as a concept is fundamental to a reliable system.
      • ashtonkem 5y ago
        I see where you’re going, but I think if we start defining tests as part of observability then we’ll water that term down to meaninglessness.
        • snovv_crash 5y ago
          If there's a bug and no test suite to try to reproduce it, how do you know you actually fixed it?
          • ashtonkem 5y ago
            I define observability as the tools I use to check on the behavior of my system in ad-how ways in production. This is quite different from tests, which are designed to exercise specific behavior in a fixed environment. Both are used towards the goal of software quality, but they’re different.
• skinnyarms 5y ago
  Am I missing something, it sounds like they are already doing this - not striking off on a new venture.
  • hatsuseno 5y ago
    > I have to admit, that I didn't know what TDD really was until recently. They do already do this (hence the blogpost), but it's something kovarex hasn't explored before, so they're pretty new to TDD.
• cjfd 5y ago
  I learned TDD years ago and never looked back. It is true that there are some things where it is less suitable and therefore I would perhaps decide not to use it. E.g., user interfaces in case of changes that are mainly visual. Or code that tightly integrates with the system. E.g., file system manipulations. For all other code I think TDD is absolutely the best way to write anything more complicated than a throw-away script. Frankly, I am pretty much at the point where I consider anything less than TDD borderline unprofessional. I have come to expect code that was not TTD-ed to be buggy or more complicated than necessary or both.
  • echelon 5y ago
    It also seems really ill suited for new systems and places where you're experimenting with new languages or frameworks. You don't know the shape well enough to be able to test the inputs and outputs before writing the thing, and learning via TDD seems highly suboptimal.
    • rytor718 5y ago
      I think you have a fair point in regards to learning new things. YOu don't need tests to explore tools and languages. Tests are for development. Thats just the thing with TDD: used properly (which is clearly tricky for many of us), it should help you think through what the inputs and outputs of the program you hope to write are. It does assume you know what you want to build though, even if you're unsure of how to build it. I think of it as a design tool to be honest. When I'm not quite sure exactly how something should work, but I have a clear idea of what I want it to do, tests help me work through it in a way that produces extensible code.
      • user-the-name 5y ago
        It's not tools or languages you are exploring, you are exploring the problem you are trying to solve, and its possible solutions. If you have a problem that is well understood, well documented and that has a straightforward solution, TDD is great because you know where you are going. But a lot of the time, you have none of that. You don't know where you are going. You need to experiment, you need to iterate, you need to occasionally change directions completely. When you're doing that, TDD holds you back and gives you nothing.
• blacktriangle 5y ago
  You say that like its a bad thing. Sure dogmatic TDD can lead to issues, but going through a period of dogmatic TDD has, for me, resulted in becoming a far better programmer. And as time goes on I find myself drifting further back towards the dogmatic side of TDD as I know the difference how it feels working on tested portions of our code vs the untested portions of our code.
  • JohnHaugeland 5y ago
    > You say that like its a bad thing. That's because it is
  • astrange 5y ago
    It is kind of a bad thing. Recently at work there was a quality program introduced by some training guy, but by quality they seemed to mean write more tests and do TDD, and our junior engineers read that as write a ton of unit tests (the only kind they'd heard of.) I pointed out the 10 year old Norvig vs Ron Jeffries fight[1] which demonstrates that TDD is useless when you don't already know what you're writing, but they just looked confused. The other problem here is that unit tests never break (since you've mocked everything that can break) and therefore aren't worth running; it might be more productive to write them for TDD and then just not commit them. [1] https://news.ycombinator.com/item?id=3033446 https://news.ycombinator.com/item?id=3033446
    • blacktriangle 5y ago
      I agree with you, which is why I think the GPs post that TDD is not a dogma but another tool in your toolbox makes sense. Just like the larger development community when faced with new tools, individual developers go through the pattern of adoption where they start using a technique for everything (the honeymoon phase) and then through that phase they learn when the tool is appropriate and when the tool I not. As posters in your linked thread point out, the irony is that Norvig would have probably been better off using TDD since he knew the general shape of his solution already where Jeffries likely should have been writing several spikes to explore the solution space rather than using TDD since he was unfamiliar with the problem and did not yet have a good solution.
• wpietri 5y ago
  Nobody should stick to any dogma past the honeymoon period. The point of a dogma is to get you into the behavior space that you will learn how to do something well. It's like using a recipe in a cookbook. Once I had enough practice making scrambled eggs, I didn't need a recipe anymore. I learned TDD ~20 years ago from Beck's "TDD by Example" book. For me it's far more than "just another tool". I'll certainly do exploratory work with throwaway code. And in the early stages of something, I might be a bit slack. But the lesson over and over for me is that if I don't get to significant test coverage soon, I end up wasting a lot of time on bugs. And TDD is the easiest way to get to test coverage. Test-first ends up feeling like a set of small successes with the red-great-refactor loop. With test-after, going back and adding tests feels more like drudgery, and I'm less likely to have written the code in a testable way. So TDD is not dogma for me, just the inevitable place I end up if I want to maximize the amount of time getting things done while working on a non-trivial codebase.
  • wpietri 5y ago
    That said, I totally agree that Martin is a salesman. I knew him in the early days of the Agile movement and he did a lot of good then. But he's become consistently more strident, more dogmatic, more unpleasant. It's sad to see, really.
    • roguas 5y ago
      I think it's the archetypical story of you either die a hero... People find new ways to cope with complex problems, they soon become bound to those new ways.
      • wpietri 5y ago
        No, I think he's become the villain for unrelated reasons. A lot of the early Agile people are still out there doing good work. More than I'd expect, honestly; the people who are attracted to a wild, early-stage idea are a very mixed bag.
  • nightski 5y ago
    I had a similar trajectory but opposite experience. I felt like after doing heavy TDD and even FP after a while TDD felt more and more like a waste of time. I find that I naturally think and design in a test driven perspective without actually writing the tests due to many years of experience. 1.) I'd much rather lean on the type system to prove things than automated tests if possible. But of course depending on the language that often isn't possible. 2.) I find that only a small fraction of my code really benefits from automated testing. This is the logic/calculation parts of the code. The rest is slinging IO and SQL queries which all ends up being mocked out anyways and the tests just become secondary implementations of the original code.
• fendy3002 5y ago
  From my experience, tdd is useful if you already have solid specification, the code / part can be tested and you / your team understand how to develop unit / integrated tests. The problem arises because usually one or some of the points are unfulfilled. And it's not without drawbacks. Increased development time and the needs to maintain the unit tests are costly, but rewarding. Also I don't like too much interface and mocking only for the sake of testing. I find it usually breaks when integrated and makes code harder to maintain. Maybe I'm just inexperienced.
  • berkes 5y ago
    > The problem arises because usually one or some of the points are unfulfilled. An important idea of TDD is that it allows you to discover those "unfulfilled points" in the tests. When writing code (the tests) that use an API, instead of when writing the actual API. When writing code that uses objects, methods, interfaces and so on, you are in a mindset of writing "what a user of the code would wish there was". This is probably the best place, mindset and moment to define those specs in detail.
• deleted 5y ago
  [deleted]
• tziki 5y ago
  TDD, when normalized for time spent writing tests, has not been found to be any better than the 'normal' way of writing tests afterwards. It's interesting how much of programming lore falls apart when you actually try to measure the impact.
• naikrovek 5y ago
  TDD and OOP as dogmas are very bad, for different reasons. TDD encourages you to write many times the number of lines of code for your tests as the code you're testing, often 10X or more. So when you inevitably decide "there's a much better way to do this" (which happens to me 100% of the time) then you're not only changing your code, you're changing all of those tests. That's a lot of weight that you now have to deal with. Most of the time, that's enough weight that the better design simply doesn't happen and becomes yet another chunk of tech debt that prevents certain things from happening in the future. I've seen that happen, and it's given me a very bad taste in my mouth for "TDD" because "TDD inertia" is the reason that better designs aren't implemented. If that piece of software lives for a while, and grows in scope, someone is going to have to deal with that, and eventually make the architectural change anyway. By all means, test your code, of course. If you can find a way to easily generate test cases for an arbitrary code base, by all means, do that, because the test cases are no longer influencing your decision to change how your application works. Otherwise, being "test-driven" is bad, IMHO. Software development is never as simple as the various dogmas would lead you to believe.
  • CharlesW 5y ago
    > So when you inevitably decide "there's a much better way to do this" (which happens to me 100% of the time) then you're not only changing your code, you're changing all of those tests. Isn't the point of TDD that you can change implementation at will, safe in the knowledge that the tests will help guarantee that you're not inadvertently changing behavior?
    • cryvate1284 5y ago
      This depends on what you're doing. For example, if you are changing an intermediary (abstraction) layer, then the (unit) tests (TDD or not) for those will have to change and the "guarantee that you're not inadvertently changing behaviour" is kinda moot. If you do not have TDD, I guess the reasoning is that either you do not have tests for this (probably bad) and if you do, less of them (and so more easily changed). Not sure it's an argument against TDD, but I guess if management/the programmer do not know about sunk cost fallacy, it might make them hold on to bad abstractions/layers.
• mbrodersen 5y ago
  I haven’t had a bug in production for 9+ years. Not a single one. And routinely do major refactorings, feature improvements, optimisations etc. I can do it because of 9000+ tests. 1800 hand written and the rest auto generated to detect changed behaviour. The test suite allows me to spend 95% of my time adding features instead of bug fixing. Most excellent.