• VanillaGorilla@kbin.social
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    With my stakeholders TDD is nearly impossible. I mean it’s possible, but doesn’t make sense as they shuffle their specifications every other day. I implement, they decide they wanted something different, I refactor, they don’t like it, I refactor, they accept, I write tests.

    Please send help

  • ryathal@sh.itjust.works
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    Works great when you know what your doing before you start. That never actually happens in real life though.

    • Zalack@startrek.website
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      1 year ago

      And often if you box yourself into an API before you start implementing, it comes out worse.

      I always learn a lot about the problem space once I start coding, and use that knowledge to refine the API of my system as I work.

  • SmoothSurfer@lemm.ee
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    1 year ago

    Years of experience speaking:

    • Make it work
    • Make it right
    • Make it fast

    If your end results are following this pattern, no one gives a fuck how you do

  • lobut@lemmy.ca
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    I like TDD in theory and I spent so many years trying to get it perfect. I remember going to a conference where someone was teaching TDD while writing tic tac toe. Unsurprisingly, he didn’t finish in time.

    The thing that I hate is people conflating TDD with testing or unit testing. They’re vastly different things. Also, I hate mocks. I spent so long learning all the test doubles to pass interviews: what’s the difference between a spy, fake, stub, mock, etc. Also doing it with dependency injection and all that. I much prefer having an in-memory database than mock what a database does. Last company I worked at, I saw people write tests for what would happen if the API returned a 404 and they wrote code that would handle it and all that. In practice, our HTTP library would throw an exception not return with a statusCode of 404. Kinda funny.

    You obviously can’t always get replacements for things and you’ll need to mock and I get that. I just prefer to not use them if I can.

    Also, TDD advocates love saying, you’re just not doing it well or you just don’t know enough.

    I get it, you love TDD and it works for you and more power to you.

    I definitely believe in testing and having resilient tests that will minimize changes upon refactoring, but TDD doesn’t work for me for most of the work I do. It works for some and I love it when it does, but yeah … sorry random long ramble.

    • tvbusy@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      After many failed attempts at TDD, I realized/settled on test driven design, which is as simple as making sure what you’re writing can be tested. I don’t see writing the test first as a must, only good to have, but testable code is definitely a must.

      This approach is so much easier and useful in real situations, which is anything more complicated than foo/bar. Most of the time, just asking an engineer how they plan to test it will make all the difference. I don’t have to enforce my preference on anyone. I’m not restricting the team. I’m not creating a knowledge vacuum where only the seniors know how yo code and the juniors feel like they know nothing.

      Just think how you plan to test it, anyone can do that.

  • amio@kbin.social
    link
    fedilink
    arrow-up
    0
    ·
    1 year ago

    It’s criminally underutilized. Of course, one reason is that it’s hard to TDD a moving target. Since it’s also hard to get people to actually fucking specify things in a lot of real world cases, it’s just one more thing you ought to do, but aren’t allowed to.

    • Notnotmike@beehaw.org
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      I think you have a point with the moving target, but also I believe that development should pretty much always be a moving target. You should be refactoring your domain based on new experiences and new knowledge all the time. So, personally, I find integration tests much more useful, because they test the input and output of a system, rather than how it’s implemented. I can change my domain without having to modify my tests and that makes changes to the domain much simpler.

      That being said, I also definitely recognize the advantages of TDD, I just don’t think it’s a silver bullet; there’s good projects for it and bad ones