> 100% test coverage
I don’t believe in 100% test coverage. Especially outside some very specific cases, it just adds a lot of code with little to no value.
I don’t believe in 100% test coverage. Especially outside some very specific cases, it just adds a lot of code with little to no value.
Writing a good test or good set of tests does take effort but enforcing 100% coverage often pushes some folks to just run the code in any way possible within the test subsystem.
Nicely put. A very verbose type system that is also placed too far away from the definitions indeed
If I have a function add_nums that takes 2 numbers and adds them, there are like infinite inputs that can be tested.
If I have a function shape_color that can take circle, triangle, square for the shapes and red, blue, for the colors, then there are 6 different states. But what if my function just returns if it is a circle or triangle. It only cares about 2 different color paths when it is a square. Do I test all 6 states or do I test only the 3 code paths?
I think code coverage like many things is a “it depends”.
That's what formal verification is for: you generate math statements from the code, and then prove them.
Testing is for covering the most common scenarios and likely edge cases. 100% coverage means every line of code in the app is executed when your test suite runs. It is useful as a bare minimum, but by itself does not guarantee that there are no bugs.
if you are confident that the complexity of what you have built can be fully tracked in your head then either you are some sort of God or you’re not used to building complicated enough things with critical failures attached to them
func below_ten()
if 10 < x
println(“true”)
else
println(“false”)
end
end
Perhaps this is a sign that this function isn't necessary.
Unit tests aren't for verifying functions.