111–115 of 115 posts
Earlier quoted context omitted.
How easy is it test a function add(a, b) that just adds a and b and returns the result? Or how bout testing: function divide(a, b, fn) { let [_a, _b] = fn(a, b); return _a / _b; }
I meant that's an awful function. I never, ever, ever have a single letter identifier. So I can't respond yet.
Earlier quoted context omitted.
I meant that's an awful function. I never, ever, ever have a single letter identifier. So I can't respond yet.
Changed the name from m to divide. It just transforms a and b through fn and divides those values.
Earlier quoted context omitted.
Changed the name from m to divide. It just transforms a and b through fn and divides those values.
Much better, but you still have 3 meaningless identifiers. Need to narrow your names down more before I can comment.
We enforce 100% test coverage. Not 90, not 95, not 99, but 100. You need to test your code if you want to reach production. And production is the only environment we have. Having just prod generates less friction and allows us to make more changes, more features. But in order to live by this premise, the team needs to be really good at testing.
Fundamentally, no one ever said that coverage had to just be a binary of 0 or 1 as a "hit" line, though it is definitely the branding that code coverage has today.
As some others on this thread mentioned, how is something being tested should matter: - Unit vs. integration vs. end-to-end test vs. other testing - Flakiness of test (non-determinism) - Accuracy of test (E.g., mutation testion / fuzzing)
Also, What is being tested matters: - How important is this line? How is often is it actually being called in production? - Are their errors / exceptions on this line that we can see?
I do not believe that 100% coverage is the goal, nor should it be for all teams.
Do you have feedback here? I'd love to talk more about this.