• @[email protected]
    link
    fedilink
    English
    341 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.

    • @[email protected]
      link
      fedilink
      English
      51 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!

  • @[email protected]
    link
    fedilink
    English
    32
    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 😅.

  • @[email protected]
    link
    fedilink
    English
    21
    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.

  • lemmyvore
    link
    fedilink
    English
    19
    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.

    • @[email protected]
      link
      fedilink
      English
      81 year ago

      I really hate the projects I work on where they’ve overtested to the point of meaninglessness. Like every single class has a full suite of tests mocking every single dependency and it’s impossible to look at it without breaking 50 test cases.

      Similarly I hate the projects with no tests because I can’t change anything and be sure I’ve not broken some use-case I didn’t think about.

      Much prefer the middle ground with modular, loosely coupled code and just enough tests to cover all the use cases without needing to mock every single little thing. It should be possible to refactor without breaking tests.

      • @d0m
        link
        English
        11 year ago

        For real. I have been using DI to only mock infra and external services while keeping the actual code unmocked, and using an in memory db (we use Dynamodb so that’s easy) for testing. I write tests only at the interface level, send data in, mock infra, external services, and then assert side effects. Found this to work very well for now, especially for Lambdas which we have quite a lot of.

        Whenever we encounter a bug, we ensure that that case is captured in a unit test as well, but priority on integration tests.

    • @[email protected]
      link
      fedilink
      21 year ago

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

  • @[email protected]
    link
    fedilink
    English
    18
    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.

    • @[email protected]
      link
      fedilink
      English
      131 year ago

      I think it also very much depends on your tooling & how easy it feels to start writing unit tests.

      When I work in a Java project for example I always write unit tests even for personal stuff, because the IDE integration is great and it’s really quick to create a test class, run it and see granular results. I don’t feel the same way about testing JavaScript because the tooling at least for me hasn’t worked quite as well (though that could very well be my own fault, it’s been a while since I looked into it). The more cumbersome setting up and running the tests is, the more tempting it becomes to just use the console or manually test parts instead.

    • deaf_fish
      link
      fedilink
      English
      31 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.

  • @[email protected]
    link
    fedilink
    English
    171 year ago

    I hate manually verifying stuff. There’s no way I’m going to walk through all the cases I care about after making a change. So I just run my stupid tests.

    • lemmyvore
      link
      fedilink
      English
      121 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.

      • @Trashcan
        link
        English
        21 year ago

        If you don’t know what you to achieve with the code you are writing right now, then that’s your problem right there.

        I’m not saying TDD is easy, and it takes effort. But you do know what you want to do before you start coding, right? Or am I missing something here?

      • @[email protected]
        link
        fedilink
        English
        01 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

  • @[email protected]
    link
    fedilink
    English
    161 year ago

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

  • @[email protected]
    link
    fedilink
    English
    121 year ago

    Testing is so important though! It can be mind-numbingly boring, but it is an important part of software development, imo.

  • Gogo Sempai
    link
    fedilink
    English
    111 year ago

    For personal projects? Sure. At work? MR doesn’t get approved if the coverage drops even by 0.02% :(

  • @[email protected]
    link
    fedilink
    English
    101 year ago

    you’ll change your mind when it’s more effort to set up a test situation for a manual test. like when you change something that communicates with an expensive propietary API and you can’t just push it to production.

    • lemmyvore
      link
      fedilink
      English
      131 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.

      • @[email protected]
        link
        fedilink
        English
        21 year ago

        Copilot Chat uses GPT-4 and can see more context than just the line you’re on. It has more reasoning than the autocomplete model.

      • @[email protected]
        link
        fedilink
        English
        11 year ago

        Copilot happily writes failing testa too, TDD style. It just generates code tests that are very common and probably won’t catch those hard to miss cases anyway.

  • chris.
    link
    fedilink
    English
    81 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

  • qtieπ
    link
    fedilink
    English
    71 year ago

    whoah okay no need for personal attacks

  • @[email protected]
    link
    fedilink
    English
    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.