Test coverage doesn't really mean much, and every situation is different.
In a library I wrote, I use a Python dict to store a bunch of lambda functions, and have another function that gets one and calls it.
Just because the code is "covered" it doesn't mean that there are no bugs in it. (Of course, I have tests that give me confidence that it works, as I've used TDD to write those rules and test each function extensively).
As far as pytest is concerned, if it hits the dict definition, that code is covered. It doesn't care about calling the lambda functions.
As it's a reusable library, I really like testing it extensively - and it's very easy to get to 100%.
If I work on a website / web app, I will test some back-end things in pytest, some front-end in jest, and some in cypress, and worry more about being confident in my tests than getting to some magic threshold.
I may be reasonably confident something works even without automated testing. My threshold for acceptable confidence varies on whether something is a side project, or an app that handles customer payments, or if I'm prototyping as opposed to writing production code.
Sometimes, manual testing is good enough for me... Context is important.
I do love automated testing, for the record, and think it's important. Just be pragmatic about it.
Sure, I tend to skip testing entirely for the first release. Gotta get something out there first.
I also accept manual testing IF you only have like 2 end points but probably only for a single update or temp fix. Long term nothing beats automated tests.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Test coverage doesn't really mean much, and every situation is different.
In a library I wrote, I use a Python dict to store a bunch of lambda functions, and have another function that gets one and calls it.
Just because the code is "covered" it doesn't mean that there are no bugs in it. (Of course, I have tests that give me confidence that it works, as I've used TDD to write those rules and test each function extensively).
As far as
pytestis concerned, if it hits the dict definition, that code is covered. It doesn't care about calling the lambda functions.As it's a reusable library, I really like testing it extensively - and it's very easy to get to 100%.
If I work on a website / web app, I will test some back-end things in
pytest, some front-end injest, and some incypress, and worry more about being confident in my tests than getting to some magic threshold.Agree, code coverage to me is a sanity check in things I may have missed. But TDD or similar helps give me the confidence I need.
Having a test cover a line of code is not as good as being confident it works. But, I know if it's not covered I am not confident at all it works.
I may be reasonably confident something works even without automated testing. My threshold for acceptable confidence varies on whether something is a side project, or an app that handles customer payments, or if I'm prototyping as opposed to writing production code.
Sometimes, manual testing is good enough for me... Context is important.
I do love automated testing, for the record, and think it's important. Just be pragmatic about it.
Sure, I tend to skip testing entirely for the first release. Gotta get something out there first.
I also accept manual testing IF you only have like 2 end points but probably only for a single update or temp fix. Long term nothing beats automated tests.