I hacked plunit/test_cover.pl to give me clause-level coverage information. I was able to determine that I had over 96% coverage and was able to show the exact clauses that weren’t executed (show_coverage/1 merely said 87.8% coverage, with no indication of what wasn’t covered). But I want to go dee…

@jan In creating some test cases for show_coverage/1,2 I know the following The test cases will be based on SWI-Prolog unit testing . The tests will use begin_test/1,2 The tests will be in SWI-Prolog package plunit https://github.com/SWI-Prolog/packages-plunit List items such as arguments should…

Tests that are part of the system all follow some very simple rules: That are named test_*.pl The define a module with name equaling the base name of the file. They export a single predicate with the same name and zero arity. The test is supposed to succeed iff the predicate succeeds. The tests mu…

I have a slightly different view of unit tests – they should aim for 100% coverage, especially with a “dynamically typed” language such as Prolog. (And if you work at Google, you’ll be indoctrinated with this view – and I’ve seen it pay off; for example, when Python changed its hashing function, man…

There are two reasons for tests: make sure changes do not introduce bugs and be at least notified if behavior changes. I don’t think all behavior changes should be considered bugs. For example, I think it is fine if member/2 would at some point complain if the second argument is not a list. Ch…

[image] jan: I think it is fine if member/2 would at some point complain if the second argument is not a list But it’s still OK to have a unit test that member(x,foo) fails – it could also have a comment saying that this behavior might change in the future (and when the behavior is changed, t…

[image] swi: c_import, cpp_const, c_define are marked as not entered Also anything expanded by library(apply_macros), although it’s easy enough to turn this off to get proper coverage information.

[image] peter.ludemann: lthough it’s easy enough to turn this off to get proper coverage information. how do you turn it off?

I guess color(true) (false) is the most sensible. As for other formats, I do not know. If there exists a format that is used by IDEs, that surely makes sense. Note that disabling coloring is as easy as either temporary switching off the color flag or do not not pretend the output is a tty.

[image] swi: how do you turn [library(apply_mcaros)] off? If your code contains :-use_module(library(apply_macros)), then simply remove it (or comment it out). Note that apply_macros contains a definition for user:goal_expansion/2, so every directive that loads apply_macros needs to be remove…

I guess emitting HTML is a different beast. That quite naturally would imply using color, as why else would you want HTML? I doubt emitting HTML makes much sense unless you either combine it with the HTML pretty printer in the pldoc package. That means more dependencies :frowning: My motto is…

Granular code coverage tool?

Discussion

peter.ludemann July 29, 2021, 5:34pm 40

You should be able to get the information programmatically by adding a message hook.

Topic		Replies	Views
Any programatic way to obtain rules used to prove a goal? Help!	18	1241	February 18, 2020
Improving unit tests Request For Comments	36	1164	February 2, 2023
PLunit How-To / teaching example Help!	2	1004	December 2, 2019
Bug hunting toolbox Wiki	2	2929	May 17, 2025
Coverage info mysterioulsy disapear Help! bug	12	537	September 16, 2022

Granular code coverage tool?

Related topics