• lonlazarus@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    5
    ·
    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.

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

      Good tests remove development time, not add to it.

      I can’t tell you the countless hours saved from automated testing. Red Green refactor for life!

  • PoolloverNathan@programming.dev
    link
    fedilink
    English
    arrow-up
    2
    ·
    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.

  • bleistift2@feddit.de
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    I’m a frontend developer. All the meaningful tests always break for the stupidest, obscure reasons. That’s why I don’t write tests.

  • asyncrosaurus@programming.dev
    link
    fedilink
    English
    arrow-up
    2
    ·
    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.

  • Rooster@infosec.pub
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    When you can press “Go” and dozens of little green lights light up? That’s the stuff.

  • 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.

    • bleistift2@feddit.de
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      This. Just thinking about how you would test something leads to better code, at least in my experience.

  • argv_minus_one@beehaw.org
    link
    fedilink
    English
    arrow-up
    1
    ·
    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.

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

      TDD is pretty difficult when you don’t have a very clear idea of what’s the best way to achieve what you want to do – which is most projects most of the time.

      It’s usually also a hard sell for management, especially if the project is on its first steps and it has to show something functional in order to keep its budget.

      Last but not least, the problem domain for unit tests is pretty focused. The parts of the code that are suited for unit testing may not be all that much. I know that TDD is not just unit tests but I mentioned it in the context of this discussion.

      • renovator_sinner_wisdom_headdress@programming.dev
        link
        fedilink
        English
        arrow-up
        0
        arrow-down
        1
        ·
        1 year ago

        1st problem - you should be coding such that you can make at least two iterations. It should be perfectly okay to code it once so that you have an idea and then throw it out and do it correctly. If you work in sufficiently small steps, there’s barely any time waste plus you save time that you would spend maintaining

        2nd problem - Kent Beck’s (the guy who “invented” TDD) idea behind TDD was that it should help you be less stressed. If your job is to make a prototype or get something really out the door really fast and you won’t lose sleep over it, then there is no need to write tests. TDD is there to enable you.

        I am not exactly sure, what you mean with the unit tests, so apologies if I am misunderstanding. I use integration tests in my red-green-refactor loop as well

  • 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.

  • festus@lemmy.ca
    link
    fedilink
    English
    arrow-up
    1
    ·
    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 😅.

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

      A good unit test is an expression of the intent of the programmer that wrote the unit of code. How would Copilot know what your intent was?

      What Copilot does is to test exactly what the code is currently doing… which kinda defeats the purpose.

      But it does raise a good point, because that’s usually exactly what teams are asked to do (especially when there’s a high coverage requirement). It’s completely pointless busywork, but that’s what makes it perfect for Copilot.

    • 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.

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

      No. If your goal is to move towards automated testing, see what language is used by the most popular automated frameworks and pick up a beginner’s tutorial for that language.