> outside of our bubble the quality of software is pretty bad
It's pretty bad inside the bubble too.
It's pretty bad inside the bubble too.
.0001% of that software had formal verification, bitwise memory management, 100% test coverage, clean documentation and specifications, a clear roadmap, long term sustainability plan and sustainable economics
Technology is like a good meal: only possible for a moment and only a moment.
too early and it’s inedible too late and it’s spoiled.
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 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.
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.
User testing is part of test coverage
At least that is true for my software coding processes; I always found getting the actual coders talking directly to the actual users — not the managers talking to the managers — vastly improved the software delivered along all three axes of schedule, budget, and quality, and dramatically reduced test/redo cycles. Just having the coders in direct contact, they hear about the real used cases, edge cases, and frustrations, and so can make good judgements about many decisions, rather than blind judgements.