Comment on AI Coding Is Massively Overhyped, Report Finds

• MangoCats@feddit.it ⁨6⁩ ⁨months⁩ ago

  I’m mixed on unit tests - there are some things the developer will know (white box) about edge cases etc. that others likely wouldn’t, and they should definitely have input on those tests. On the other hand, independence of review is a very important aspect of “harnessing the power of the team.” If you’ve got one guy who gathers the requirements, implements the code, writes the tests, and declares the requirements fulfilled, that better be one outstandingly brilliant guy with all the time on his hands he needs to do the jobs right. If you’re trying to leverage the talents of 20 people to make a better product, having them all be solo-virtuoso actors working independently alongside each other is more likely to create conflict, chaos, duplication, and massive holes of missed opportunities and unforeseen problems in the project.

  source

  • Nalivai@lemmy.world ⁨6⁩ ⁨months⁩ ago

    independence of review is a very important aspect of “harnessing the power of the team.”

    Yep, that’s basically my rationale

    source
• sugar_in_your_tea@sh.itjust.works ⁨6⁩ ⁨months⁩ ago

  I really disagree here. If someone else is writing your unit tests, that means one of the following is true:

  • the tests are written after the code is merged - there will be gaps, and the second dev will be lazy in writing those tests
  • the tests are written before the code is worked on (TDD) - everything would take twice as long because each dev essentially needs to write the code again, and there’s no way you’re going to consistently cover everything the first time

  Devs should write their tests, and reviewers should ensure the tests do a good job covering the logic. At the end of the day, the dev is responsible for the correctness of their code, so this makes the most sense to me.

  source

  • Nalivai@lemmy.world ⁨6⁩ ⁨months⁩ ago

    the tests are written after the code is merged - there will be gaps, and the second dev will be lazy in writing those tests

    I don’t really see how this follows. Why do the second one necessary have to be lazy, and what stops the first one from being lazy as well.
    The reason I like it to be different people is so there are two sets of eyes looking at the same problem without the need for doing a job twice. If you miss something while implementing, it’s easier for you to miss it during test writing. It’s very hard to switch to testing the concept and not the specific implementation, but if you weren’t the one implementing it, you’re not “married” to the code and it’s easier for you to spot the gaps.

    source

    • sugar_in_your_tea@sh.itjust.works ⁨6⁩ ⁨months⁩ ago

      Devs are more invested in code they wrote themselves. When I’m writing tests for something I didn’t write, I’m less personally invested in it. Looking at PRs by other devs when we do pushes for improving coverage, I’m not alone here. That’s just human psychology, you care more about things you built than things you didn’t.

      I think testing should be an integral part of the dev process. I don’t think any code should be merged until there are tests proving its correctness. Having someone else write the tests encourages handing tests to jr devs since they’re “lower priority.”

      source

      • Nalivai@lemmy.world ⁨5⁩ ⁨months⁩ ago

        Devs are more invested in code they wrote themselves. When I’m writing tests for something I didn’t write, I’m less personally invested in it.

        This, I think, is a very bad part of the problem and shouldn’t be happening regardless

        source

        • -> View More Comments