(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!
Change step 2 to “Commit and push ONLY when absolutely necessary. Because adding comments often requires a rewrite of untestable code.”
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.
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”.
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.
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.
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.
Ah, the classical “just introduce tests in a legacy codebase”, what can go wrong?
My condolences, it’s always a BITCH to handle
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”.
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.
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.