• Vlyn@lemmy.world
    link
    fedilink
    English
    arrow-up
    173
    arrow-down
    4
    ·
    1 year 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.

    • b1ab@lem.monster
      link
      fedilink
      English
      arrow-up
      31
      ·
      1 year 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@kbin.social
        link
        fedilink
        arrow-up
        21
        ·
        1 year 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”.

    • ChickenLadyLovesLife@lemmy.world
      link
      fedilink
      English
      arrow-up
      26
      arrow-down
      1
      ·
      1 year 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.

    • ahal@lemmy.ca
      link
      fedilink
      arrow-up
      14
      ·
      1 year 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
        arrow-up
        9
        ·
        1 year 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.

    • PeriodicallyPedantic@lemmy.ca
      link
      fedilink
      arrow-up
      6
      arrow-down
      2
      ·
      1 year ago

      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.

    • evatronic@lemm.ee
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

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