`self.initfp()` is very unlikely raise exceptions. But MemoryError,
KeyboardInterrupt or
other rare exceptions may be happen.
unittest.mock helps a lot to test such corner case: mock initfp() with a
MemoryError side effect, maybe also close () to check that the method was
called... The new probl
> While I use code coverage to improve automated unittesting, I am opposed to
> turning a usable but limited and sometime faulty tool into a blind robotic
> master that blocks improvements. The prospect of this being done has
> discouraged me from learning the new system. (More on 'faulty tool' l
On 4/25/2017 11:00 AM, Barry Warsaw wrote:
On Apr 24, 2017, at 09:32 PM, Ethan Furman wrote:
On 04/21/2017 03:29 PM, Victor Stinner wrote:
(In the context of having a patch blocked by the blind Codecov robot ...)
I dislike code coverage because there is a temptation to write artificial
tests
On Apr 24, 2017, at 09:32 PM, Ethan Furman wrote:
>> I dislike code coverage because there is a temptation to write artficial
>> tests whereas the code is tested indirectly or the code is not important
>> enough to *require* tests.
>
>If it's not important enough to require tests it's not importan
