• ryathal@sh.itjust.works
    link
    fedilink
    arrow-up
    4
    ·
    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
      2
      ·
      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
    3
    ·
    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

  • VanillaGorilla@kbin.social
    link
    fedilink
    arrow-up
    3
    ·
    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

  • lobut@lemmy.ca
    link
    fedilink
    arrow-up
    2
    ·
    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
      2
      ·
      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.

  • JackbyDev@programming.dev
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    I write my code, comment it out, write tests that fail, then uncomment my code, then do the proper TDD loop. Some folks get too strict about the process at the beginning saying that that a test that doesn’t compile is still a failing test. My brain doesn’t work like that.

  • amio@kbin.social
    link
    fedilink
    arrow-up
    2
    ·
    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

    • Spike@discuss.tchncs.de
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      There’s some things called software architecture, requirement engineering and software design. More dev teams should try this.

    • MajorHavoc@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      The dev who don’t know how to TDD their poorly designed object oriented spaghetti code are downvoting you, lol. Wear that with pride, but be sure to charge extra when it’s time to fix their shit.

  • RoadieRich@midwest.social
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    1
    ·
    1 year ago

    It’s definitely great in theory until you inherit a codebase with no tests, poor documentation, and numerous reported bugs already live in production. Even better if it was written by people hired because they could do other things better than they could code - which looking at some of the unlabeled wiring messes we were left, isn’t saying a lot.

  • Gnubyte@lemdit.com
    link
    fedilink
    English
    arrow-up
    0
    arrow-down
    1
    ·
    1 year ago

    Write code to test your code then repl build and run it anyways and smoketest it to see if it actually works

    Sounds like activities for people who don’t have real work to do. These tech layoffs cut deep because there was so much fluff in the industry. I sort of blame these companies that marketed devops too hard and oversold overcomplicated solutions, but it’s also the fault of the tech leads advising managers.