• asyncrosaurus@programming.dev
    link
    fedilink
    English
    arrow-up
    15
    arrow-down
    1
    ·
    edit-2
    1 year ago

    Not testing is crazy. Once you realize you can actually refactor without ever having the fear you’ve broken something, there’s actually opportunity to make rapid improvments in structure and performance. Taking 2 minutes to write the test can save your hours of debugging. Unless you’re building a throwaway prototype, not unit testing is always the wrong choice.

  • festus@lemmy.ca
    link
    fedilink
    English
    arrow-up
    14
    ·
    edit-2
    1 year ago

    One rule of thumb I’ve heard and follow is that every time you encounter a bug, you write a unit test that would catch it. I find that does a pretty good job of getting high code coverage, though maybe that’s cause my code is naturally buggy 😅.

  • nibblebit@programming.dev
    link
    fedilink
    English
    arrow-up
    13
    arrow-down
    1
    ·
    edit-2
    1 year ago

    All you folks are crazy not to unit test personal projects. Unit tests don’t need to be fancy and exhaustive. A sanity check and having a simple way to execute isolated code is well worth the 15 minutes of setting it up. Heck, just use them as scratch files to try out libraries and APIs. I can’t imagine having the kind of time to raw-dog that f12 button and sifting through print() nonsense all night.

    • deaf_fish@lemm.ee
      link
      fedilink
      English
      arrow-up
      3
      ·
      1 year ago

      If I ever want to take a break from my personal project and come back to it. Unit tests are necessary. If I try to continue working on a project that doesn’t have unit tests. I feel like every bit of code I touch is introducing countless hours of debugging. It really demoralizes me.

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

    Simple, design your code in a way that makes it untestable. Edit: For bonus points, design your code in a way that makes it unreadable.

  • chris.@beehaw.org
    link
    fedilink
    English
    arrow-up
    6
    ·
    1 year ago

    this especially makes you feel idiotic when you spend a long ass time finding & fixing a simple bug resulting from a typo then realize that it would’ve been caught immediately if you just wrote tests like you said you would 3 days ago

  • argv_minus_one@beehaw.org
    link
    fedilink
    English
    arrow-up
    4
    ·
    1 year ago

    Writing good tests is foxtrotting hard, don’t kid yourself.

    Writing good tests that are actually readable and thoroughly exercise the code under test is damn near impossible.

    Send help.

    • Mot@beehaw.org
      link
      fedilink
      English
      arrow-up
      3
      ·
      1 year ago

      So so many unit tests I see don’t meaningfully test anything. It would be faster to just read the unit under test because the test itself presents nothing that you wouldn’t instantly recognize. Or the test is so tightly coupled to some arbitrary property that of course the test fails whenever you change something. UI tests at my current place are terrible for this, as they’re just comparing DOM structures so any change breaks it.

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

          It’s not the worst thing. Like any other test there are more and less valuable methods. Imo, the hardest part is not coupling yourself to the incidental. All tests have that issue but UIs are almost entirely incidental. Styles, layout, and even data and function can be incidental and thus likely to change.

  • lonlazarus@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    3
    ·
    1 year ago

    Not writing unit tests just isn’t an option for a reliable app in the long term. But, it’ll take way more than 10 minutes, always.

    • jeff 👨‍💻@programming.devOP
      link
      fedilink
      English
      arrow-up
      5
      ·
      1 year ago

      Ask your boss if there are paths for you to learn automated testing. It’s a somewhat common career path for manual QA to become an SDET.

  • lemmyvore@feddit.nl
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    1 year ago

    Here’s my take. In order to be able to write meaningful unit tests the code should be structured in a certain way, with very modular, decoupled units, dependency injection, favoring composition and polymorphism over inheritance and so on.

    If you manage to write your code this way it will be an objective advantage that will benefit the project even if you don’t write a single unit test. But it does make unit tests much easier to write, so presumably you’ll end up with more tests than otherwise.

    IMO teams should prioritize this way of writing code over high test coverage of non-modular code. Unit tests for deeply-coupled code are a nightmare to write and maintain and are usually mostly meaningless too.

    • fart@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      0
      ·
      1 year ago

      i have never written a unit test for a personal project in my life it’s not worth the overhead imo

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

        I prefer acceptance tests or end-to-end tests mostly for personal projects. Libraries I write will have unit tests though.

        However, for the most part. Personal projects are a lot of prototyping and throwing away. Unit testing and testing in general can get in the way of that.

  • ItsMeForRealNow@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    At least for frontend development, with new faster e2e testing frameworks that can even record the test while you see your work in a browser, lately I’ve been feeling I want to write more e2e tests and less unit tests.