3 ms·

If you're a sole developer you can do quite a few things short of bringing in other developers: good test coverage, linters and formatters (in git pre-commit ho

by danjac 4y ago

If you're a sole developer you can do quite a few things short of bringing in other developers: good test coverage, linters and formatters (in git pre-commit hooks or CI) etc. For example, I try to aim for 100% test coverage in solo projects - that might be overkill in a project of multiple team members all reviewers and testing each others' code, but keeps me from making stupid mistakes when there's no-one else looking over my shoulder. Another thing is how much you dog-food your project - if you are building something you use yourself every day, you are going to surface bugs and feature requirements better.

sethammons 4y ago
This note serves mostly to stand vigil against project requirements for 100% coverage, which I've seen a few clueless leads or managers attempt to implement for teams. 100% code coverage as a requirement is usually a waste of time and resources. Test code, especially units, at their edges. This frees you to change implementation details while preserving functionality. In two decades of experience, the best codebases I've worked on have around 50-80% coverage in unit tests. 100% is a false sense of security as bugs still present themselves to users. I've also seen devs burn days of effort chasing code coverage metrics, days of nearly zero-value add to the quality of the project. I completely agree that "good test coverage" is critical; I've just not seen that it extends to 100%. Pre-commit hooks for linting and formatting and automatic test runs are all best practices. Dog fooding does some amazing things in terms of usability.
- danjac 4y ago
  I mean sure, in principle I'd agree with the 50-60% for the average team as a decent metric (and as a caveat, targeting the most business critical or complex parts of the software). As a single developer (and time and needs allowing, of course: a throwaway little project might not warrant any testing) I aim to get as high as possible just because I don't have that coverage that comes from having other people looking at my code. I know there will still be bugs, particularly in harder-to-test things like the UI, browser issues etc, but it gives me more confidence to move a bit quicker when I don't have others to check me.

by danjac 4y ago

sethammons 4y ago

This note serves mostly to stand vigil against project requirements for 100% coverage, which I've seen a few clueless leads or managers attempt to implement for teams. 100% code coverage as a requirement is usually a waste of time and resources. Test code, especially units, at their edges. This frees you to change implementation details while preserving functionality. In two decades of experience, the best codebases I've worked on have around 50-80% coverage in unit tests. 100% is a false sense of security as bugs still present themselves to users. I've also seen devs burn days of effort chasing code coverage metrics, days of nearly zero-value add to the quality of the project. I completely agree that "good test coverage" is critical; I've just not seen that it extends to 100%. Pre-commit hooks for linting and formatting and automatic test runs are all best practices. Dog fooding does some amazing things in terms of usability.

danjac 4y ago
I mean sure, in principle I'd agree with the 50-60% for the average team as a decent metric (and as a caveat, targeting the most business critical or complex parts of the software). As a single developer (and time and needs allowing, of course: a throwaway little project might not warrant any testing) I aim to get as high as possible just because I don't have that coverage that comes from having other people looking at my code. I know there will still be bugs, particularly in harder-to-test things like the UI, browser issues etc, but it gives me more confidence to move a bit quicker when I don't have others to check me.