807
Well well well. (lemmy.ml)
submitted 1 year ago by to c/programmer_humor@programming.dev
130 comments fedilink hide all child comments
 

Yeah learned this the hard way.

you are viewing a single comment's thread
view the rest of the comments
[–] 8 points 1 year ago* (last edited 1 year ago) (5 children)
  1. (3) Get annoyed by constantly increasing Code Coverage Requirements on untestable (often legacy) code. Even afding comments requires code coverage go up! Line must always go up!
  2. Change step 2 to "Commit and push ONLY when absolutely necessary. Because adding comments often requires a rewrite of untestable code."
  3. Go back to Step 2 and wait for a major bug.
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 3 points 1 year ago* (2 children)

    Our company "architects" decided we needed 80% coverage minimum. On a mostly .Net 4.8 codebase. Hundreds of programs used in prod, with barely any tests in sight.
    It's a fucking nightmare.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 1 year ago (1 child)

    Ah, the classical "just introduce tests in a legacy codebase", what can go wrong?

    My condolences, it's always a BITCH to handle

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 1 year ago

    Fixing that bug you just found in prod : half a day. Adding enough tests so the app is now at 80% coverage : a whole fucking week. My student colleague was not impressed. I was like "yup, that's what jobs are like".

  • permalink
  • fedilink
  • source
  • parent
  • [–] 3 points 1 year ago*

    Why would you care about code coverage requirements on a branch that is currently in development? My work in progress commits might not build because they don't even compile, let alone have passing tests. The only time I care about the build passing and meeting requirements is when I'm ready to create the pull request.

    Also code coverage is a useless metric, but that's a different story.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 1 year ago

    3 is not related to using git in any way. I'm not really sure what you mean in 4. I didn't mean making a lot of changes, I meant that you should not wait with committing until you have a finished feature / fix / whatever. Commit after each refactor, commit after adding a new testable unit. It's always better to have more checkpoints. If your team does code review, they will appreciate atomic commits too.

  • permalink
  • fedilink
  • source
  • parent