this post was submitted on 03 Mar 2024
35 points (90.7% liked)
Programming
17436 readers
263 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Test coverage alone is meaningless, you need to think about input-coversge as well, and that's where you can spend almost an infinite amount of time. At some point you also have to ship stuff.
You get it!
Fully agreed things need to get shipped but that's why I'm a fan of test driven development. You'll always have your tests written with your feature.
Then again even if someone does it after as long as you write a test every time you write a feature you'll eventually have the code base covered.
Input coverage is new to me, mind linking me some info so I can learn? (Yes google exists but if someone has the low down on a good source I'd prefer that)
By input coverage I just mean that you test with different inputs. It doesn't matter if you have 100% code coverage, if you only tested with the number "1", and the code crashes if you give it a negative number.
If you can prove that your code can't crash (e.g. using types), it's a lot more valuable then spending time thinking about potentially problematic inputs and writing individual tests for them (there ate tools thst help with this, but they are not perfect).
Ahhh gotcha gotcha. I was doing this by default in my python testing, glad I was doing things right