Re: [python-committers] Codecov and PR

On Fri, 28 Apr 2017 at 02:19 Michael Foord wrote: > > > On 28/04/17 01:49, Terry Reedy wrote: > > On 4/27/2017 3:44 PM, Brett Cannon wrote: > >> > >> > >> On Wed, 26 Apr 2017 at 22:36 Terry Reedy >> > wrote: > >> > >> On 4/26/2017 1:45 PM, Brett Cannon wrote: > > > >

Re: [python-committers] Codecov and PR

On 28/04/17 01:49, Terry Reedy wrote: On 4/27/2017 3:44 PM, Brett Cannon wrote: On Wed, 26 Apr 2017 at 22:36 Terry Reedy > wrote: On 4/26/2017 1:45 PM, Brett Cannon wrote: > E.g. I don't expect > test_importlib to be directly responsible for exerci

Re: [python-committers] Codecov and PR

On 4/27/2017 3:44 PM, Brett Cannon wrote: On Wed, 26 Apr 2017 at 22:36 Terry Reedy > wrote: On 4/26/2017 1:45 PM, Brett Cannon wrote: > E.g. I don't expect > test_importlib to be directly responsible for exercising all code in > importlib, just t

Re: [python-committers] Codecov and PR

On Wed, 26 Apr 2017 at 22:36 Terry Reedy wrote: > On 4/26/2017 1:45 PM, Brett Cannon wrote: > > > > On Tue, 25 Apr 2017 at 17:00 Terry Reedy > > wrote: > > > While I use code coverage to improve automated unittesting, I am > opposed > > to turning a usable but li

Re: [python-committers] Codecov and PR

On 4/27/2017 1:52 AM, Ethan Furman wrote: On 04/26/2017 10:35 PM, Terry Reedy wrote: On 4/26/2017 1:45 PM, Brett Cannon wrote: :) But they are at least executed which is what we're really measuring here and I think all Ethan and I are advocating for. I thought Ethan was advocating for more

Re: [python-committers] Codecov and PR

On 04/26/2017 10:35 PM, Terry Reedy wrote: On 4/26/2017 1:45 PM, Brett Cannon wrote: :) But they are at least executed which is what we're really measuring here and I think all Ethan and I are advocating for. I thought Ethan was advocating for more -- a specific unittest for each line. I'

Re: [python-committers] Codecov and PR

On 4/26/2017 1:45 PM, Brett Cannon wrote: On Tue, 25 Apr 2017 at 17:00 Terry Reedy > wrote: 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 b

Re: [python-committers] Codecov and PR

On Tue, 25 Apr 2017 at 17:00 Terry Reedy wrote: > 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

Re: [python-committers] Codecov and PR

On 04/25/2017 11:05 PM, Victor Stinner wrote: On 04/25/2017 10:15 PM, INADA Naoki wrote: `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(

Re: [python-committers] Codecov and PR

On 04/25/2017 10:15 PM, INADA Naoki wrote: This is one examples I merged "untested line of code". https://github.com/python/cpython/pull/162/files#diff-0ad86c44e7866421ecaa5ad2c0edb0e2R552 +file_object = builtins.open(f, 'wb') +try: +self.initfp(file_obje

Re: [python-committers] Codecov and PR

`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

Re: [python-committers] Codecov and PR

> 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

Re: [python-committers] Codecov and PR

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

Re: [python-committers] Codecov and PR

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

Re: [python-committers] Codecov and PR

On 04/21/2017 03:29 PM, Victor Stinner 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 important enough to

Re: [python-committers] Codecov and PR

Thank you, I will take a look and see if I can help. Victor Le 22 avr. 2017 6:43 PM, "Brett Cannon" a écrit : > > > On Fri, 21 Apr 2017 at 15:33 Victor Stinner > wrote: > >> Ah, I found a workaround: Firefox on Android has a "[x] See the computer >> version" option which allows the merge!? >>

Re: [python-committers] Codecov and PR

Oh, I forgot something about Codecov: it took me 2 minutes to understand why a PR gets the red icon whereas all tests pass and the merge button was waiting for my click. In fact, Codecov failed but the test isn't blocking. I would expect the green icon on the overall list of PR. Well, it's not blo

Re: [python-committers] Codecov and PR

On Fri, 21 Apr 2017 at 15:33 Victor Stinner wrote: > Ah, I found a workaround: Firefox on Android has a "[x] See the computer > version" option which allows the merge!? > > Victor > > Le 22 avr. 2017 12:29 AM, "Victor Stinner" a > écrit : > >> Hi, >> >> I tried to merge a pull request on my phon

Re: [python-committers] Codecov and PR

Ah, I found a workaround: Firefox on Android has a "[x] See the computer version" option which allows the merge!? Victor Le 22 avr. 2017 12:29 AM, "Victor Stinner" a écrit : > Hi, > > I tried to merge a pull request on my phone, but I got the error: > > "Pull requests that have a failing status