We are in a very funny situation where I just spent two weeks fixing FE bugs and there are so many left. I asked to add integration tests but the answer was “no”, cause we can’t test the UI and all of that.

So the proposed solution was to be more careful, except I’m careful but testing whole website parts or the whole website is not feasible. What can I do?

  • FlumPHP@programming.dev
    link
    fedilink
    arrow-up
    11
    arrow-down
    3
    ·
    1 year ago

    Just add them. You’re a developer and automated testing is one of our tools. A woodworker wouldn’t ask permission to sand.

      • glitches_brew@lemmy.world
        link
        fedilink
        arrow-up
        4
        ·
        edit-2
        1 year ago

        Sounds like you need to answer back with numbers.

        Calculate how much time is needed for writing tests.

        Then calculate how much time was spent writing ineffective code, then add the amount of time it took to rewrite that same code.

        I guarantee the latter amount will be more.

        Bonus points if you can calculate the amount of money lost from an unavailable application, then add in the amount of money lost from the confidence your customers are losing in that app.

        • CmdrKeen@lemmy.today
          cake
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          How do you calculate those numbers though?

          It’s not like your colleagues will be keeping track of how much time they’ve wasted writing ineffective code. If anything, they’ll try to hide that by arbitrarily inflating sprint points etc.

          I’ve worked in environments like that and the issue almost always isn’t that people wouldn’t LIKE it if there were tests, it’s that they

          1. Don’t want to have to learn something new in order to do the same job they’re already comfortable with
          2. Are worried that if they convince management to let them invest X amount of time into doing something that will improve productivity, they’ll be expected to be more productive in the future

          And of course, all of this for no extra money. Unless you work at a place where management prioritzes developer happiness over how many sprint points the team can knock out every week (and those are rare), the sad truth is that it’ll likely be about as popular as leftover food growing mold in the community fridge.

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

      Exactly this. They aren’t for the company, they’re for you to have confidence that your shipped code isn’t going to blow anything up.