Its definitely a bad idea writing new code that builds up on your old code, that has not been tested properly, because you quickly have to start debugging multiple layer is code at once.

  • bleistift2@sopuli.xyz
    link
    fedilink
    English
    arrow-up
    8
    ·
    13 days ago

    Opposing opinion: If it’s legacy code, and no-one has found a bug yet, it works as intended.

    No, I don’t mean that ironically.

  • 9point6@lemmy.world
    link
    fedilink
    arrow-up
    7
    ·
    13 days ago

    Honestly this is the reason TDD is most important for personal projects.

    If it’s your job, the code isn’t getting merged without decent tests. Yes you should probably write them first so you think about your implementation properly, but let’s face it, many tests are written after in practice.

    If it’s something written in your free time, you’re just not writing those tests most of the time if you didn’t write them up front.

    • dejected_warp_core@lemmy.world
      link
      fedilink
      arrow-up
      4
      ·
      13 days ago

      Writing the tests first, or at least in tandem with your code, is the only way to fly. It’s like publishing a proof along with your code.

      it sounds trite: make the tests fit the code. Yes, it’s a little more work to accomplish. The key here is that refactors of any scale become trivial to implement when you have unit-test coverage greater than 80%. This lets you extend your code with ease since that usually requires some refactor on some level.

      • chellomere@lemmy.world
        link
        fedilink
        arrow-up
        3
        ·
        13 days ago

        This! Also, it’s a solid base to stand on when you want to optimize your code. Performing optimizations becomes much easier, quicker and fraught with errors once you have a unit test suite that will instantly tell you whether your change is working or not.

    • BlueKey@fedia.io
      link
      fedilink
      arrow-up
      3
      ·
      13 days ago

      I tried TDD in a personal project recently and it got annoying pretty fast. It was also a project where I tried a new Framework so writing test when one doesn’t know how things behave exactly results in adjusting the tests afterwards anyway.
      Thinkimg how I want to designe my API upfront while discovering the details as I go served me well in the past (still in context of personal projects).

      It also doesn’t help when my tests have more bugs than the tested code…

        • da_cow (she/her)@feddit.orgOP
          link
          fedilink
          arrow-up
          3
          ·
          13 days ago

          Ah thanks. That sounds like not that bad of an idea, but for the scale that my projects are at thus is quite an overkill. I usually try if it works in The best case sz scenario and then try to deliberately break it by calling certain functions with garbage as parameters.

          • 9point6@lemmy.world
            link
            fedilink
            arrow-up
            4
            ·
            13 days ago

            No project is too small for tests

            Tests double as your documentation for your intent

            Take it from me who has 20+ years of personal projects behind me, the ones that I’ve kept around are typically the ones that have some form of test suite.

            It’s easy to build on something if you know you’re not breaking something in the process

            • da_cow (she/her)@feddit.orgOP
              link
              fedilink
              arrow-up
              2
              ·
              13 days ago

              Yeah of course I Am testing. I Am usually just not writing very extensive tests. I try to break it as much as possible with as little effort and try then to prevent it from breaking.

  • Aneb@lemmy.world
    link
    fedilink
    arrow-up
    3
    ·
    13 days ago

    Lol I just started refactoring my codebase into a new directory to clean up my poorly stored logs and other scripts

  • socsa@piefed.social
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    13 days ago

    Test driven development means you write the test case first and then never write any additional tests.

  • ZILtoid1991@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    12 days ago

    Should I finally write a game for my game engine?

    Should I test its existing functionalities?

    No, it’s time to add a physics subsystem (which I’ll be needing for some of the games anyways).