Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: On more stable curl releases
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel F via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 22 Mar 2023 13:35:21 +0100
W dniu 2023-03-22 08:45, Daniel Stenberg via curl-library napisał(a):
> On Tue, 21 Mar 2023, Dan Fandrich via curl-library wrote:
>
>> On a related note, what's the current code coverage? I haven't tried
>> myself in a looong time, and there hasn't been a Coveralls build in 5
>> years. That would be a great graph to see on
>> https://curl.se/dashboard.html But with all the different build
>> configurations it would be hard to get a single meaningful number out
>> of it; maybe that's why it hasn't happened since then.
>
> Yes. It is practically impossible for us to get a fair or even just
> almost correct coverage number due to the many build combinations and
> the way we run different tests in different jobs etc.
>
> And apart from not getting the plain number, using the coverage data
> to detect untested code paths is then also similarly complicated.
>
> If that was not enough, the coveralls service itself was flaky and
> often triggered false positives when the coverage suddenly "dropped to
> 0%" etc.
>
> Also, frankly, even when we *know* what parts that aren't tested very
> well that does not make the masses come running to help us write new
> or expand old tests to increase coverage. I am pretty sure that we can
> dig up code areas that currently are not tested well without any
> particular tools. Right now.
One option is to provide coverage data for each platform/test job, plus
one extra created by merging results from all platform. With this
approach you could check if there are any code paths which are not
tested at all by checking merged results, and be able to check
platform-specific coverage if needed.
Date: Wed, 22 Mar 2023 13:35:21 +0100
W dniu 2023-03-22 08:45, Daniel Stenberg via curl-library napisał(a):
> On Tue, 21 Mar 2023, Dan Fandrich via curl-library wrote:
>
>> On a related note, what's the current code coverage? I haven't tried
>> myself in a looong time, and there hasn't been a Coveralls build in 5
>> years. That would be a great graph to see on
>> https://curl.se/dashboard.html But with all the different build
>> configurations it would be hard to get a single meaningful number out
>> of it; maybe that's why it hasn't happened since then.
>
> Yes. It is practically impossible for us to get a fair or even just
> almost correct coverage number due to the many build combinations and
> the way we run different tests in different jobs etc.
>
> And apart from not getting the plain number, using the coverage data
> to detect untested code paths is then also similarly complicated.
>
> If that was not enough, the coveralls service itself was flaky and
> often triggered false positives when the coverage suddenly "dropped to
> 0%" etc.
>
> Also, frankly, even when we *know* what parts that aren't tested very
> well that does not make the masses come running to help us write new
> or expand old tests to increase coverage. I am pretty sure that we can
> dig up code areas that currently are not tested well without any
> particular tools. Right now.
One option is to provide coverage data for each platform/test job, plus
one extra created by merging results from all platform. With this
approach you could check if there are any code paths which are not
tested at all by checking merged results, and be able to check
platform-specific coverage if needed.
-- Regards, Daniel -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-03-22