• @SmoothSurfer@lemm.ee
    link
    fedilink
    23
    edit-2
    2 years 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

  • JackbyDev
    link
    fedilink
    English
    172 years 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.

  • @Gnubyte@lemdit.com
    link
    fedilink
    English
    152 years 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.

      • @Gnubyte@lemdit.com
        link
        fedilink
        English
        12 years ago

        For sure but it also depends on how deep your wallets are to invest in that. Whether that means literal compensation or just your time.

    • @MajorHavoc@lemmy.world
      link
      fedilink
      22 years 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.

  • @Vlyn@lemmy.world
    link
    fedilink
    English
    1732 years ago

    TDD is great when you have a very narrow use case, for example an algorithm. Where you already know beforehand: If I throw A in B should come out. If I throw B in C should come out. If I throw Z in an error should be thrown. And so on.

    For that it’s awesome, which is mostly algorithms.

    In real CRUD apps though? You have to write the actual implementation before the tests. Because in the tests you have to mock all the dependencies you used. Come up with fake test data. Mock functions from other classes you aren’t currently testing and so on. You could try TDD for this, but then you probably spend ten times longer writing and re-writing tests :-/

    After a while it boils down to: Small unit tests where they make sense. Then system wide integration tests for complex use-cases.

    • @ChickenLadyLovesLife@lemmy.world
      link
      fedilink
      English
      262 years ago

      then you probably spend ten times longer writing and re-writing tests

      This is always what I’ve seen personally when people use TDD. And it’s worse because the inevitable time crunch towards the end of the project means the developers stop maintaining the tests, which renders all of the work put into the tests up to that point useless.

    • b1ab
      link
      fedilink
      English
      312 years ago

      Totally agree.

      I think we should all strive to do better. Unit tests, mock-ups, UX design, 2 week sprints with actual working deliverables, well documented use cases, every thing neatly stacked in Jira, dev,test,staging,prod environments, continuous integration and every thing else we are told to do.

      Then reality sets in……

      With all that said, 25 years as a dev, this utopian environment is almost impossible to find unless forced by regulatory compliance. Medical devices, life critical systems, etc. or if you have big piles of money.

      • zib
        link
        fedilink
        212 years ago

        In my experience, those things tend to be forced by project managers who believe the highest law of the land is proper scrum. Unsurprisingly, this makes all the devs miserable with no way to change anything because “this is just how it’s done”.

    • @evatronic@lemm.ee
      link
      fedilink
      English
      22 years ago

      I always start with the basics for my test cases. Like, every test case has a name, and assert(true) in the body.

    • @ahal@lemmy.ca
      link
      fedilink
      142 years ago

      It’s also great for bug fixes. Write that sucker first and you have an easy way to reproduce the issue and check whether it’s fixed.

      • @CoderKat@lemm.ee
        link
        fedilink
        English
        92 years ago

        Yeah, I’m constantly recommending junior devs to use TDD specifically for this. I don’t recommend it for anything else. If they don’t write the test first, it’s possible that the test will end up testing the wrong thing and thus they can’t be sure they really did fix the bug.

        Sometimes it’s hard to tell where to write the test ahead of time, so sometimes a slight variation I do is to write the test after (usually because it was such a struggle to figure out where the bug is), but when I’m testing it, I’ll comment out the fix or whatever and make sure the test fails.

    • I mean, it sounds more like “The messier your project, the more difficult the unit testing”. What you’re describing sounds like issues with SRP and LoD. Which will inevitably happen as big projects get rushed, but let’s place the blame where it belongs: rushing.

      Yes unit tests take longer up front, but for projects that you need to update and maintain for a long time, they’re a huge boon.

      You can’t do everything with a unit test obviously.

  • @RoadieRich@midwest.social
    link
    fedilink
    English
    62 years 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.

    • b1ab
      link
      fedilink
      English
      102 years ago

      This is very true.

      Unfortunately most product managers SUCK at designing or making software.

      Agile tries to fix this be supporting frequent iteration.

      Unfortunately most programmers SUCK at writing good code.

      TDD tries to fix this by forcing the consideration of end results (testing) at the beginning. It forces programmers and product teams to actually think and work. Make clear design decisions earlier on, but not to the point of waterfall.

      It’s just a giant cesspool of failure due to human laziness that usually falls on the shoulders of QA.

      Bottom line, making good software is hard. It takes time. But the market won’t support slow development. The business and sales teams remind me of Veruca Salt in Willy Wonka.

    • @takeda@szmer.info
      link
      fedilink
      92 years ago

      Exactly, from my experience, most of the time (primarily when I need to do something new) I start writing code, when it starts working then I am starting to refractor it so it doesn’t look like crap.

      Perhaps TDD would make sense, when before any actual work starts, we would have POC phase to understand what needs to be done.

    • @Zalack@startrek.website
      link
      fedilink
      22
      edit-2
      2 years 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.