On 31 March 2017 at 14:00, Waldek Hebisch <hebi...@math.uni.wroc.pl> wrote:
>
> Concerning coverage, it is hard to say how good it is.  If
> you mean coverage as percentage of lines of code that
> are actually executed during tests I think it is much
> higher than 10%, but lower than 100% even if you count
> only non-error handling code (it is typical that during
> testing many error do not occur, so corresponding error
> handler code is not tested).  And there is problem of
> branch coverage (if all possible destination of branches
> are taken) and path coverage.  In particular, in FriCAS
> we have parametric types and code paths depend on
> types.
>

I was thinking about how hard it might be to provide some sort of
support for automated coverage tools. As I understand it,
traditionally this is done through some sort of compiler
extension/option to "instrument" the executable code so that it logs
execution at the source statement level (say, by setting a bit in some
large bit map of the entire system) and some reporting tools to
compute the number lines of source code that actually got executed.
Doing this for Spad seems hard. For example, how does one count source
code lines for categories and/or signatures? I am not sure how this is
normally handled in other statically typed languages. Maybe this part
is not considered "executable" and so not counted in the coverage
statistics?

But it occurred to me that since package calls in FriCAS are lazy and
resolving them involves modifying some internal tables (.e.g. via the
"GoGet" macro) it might be possible in principle to use these tables
and the information about which lazy calls have been resolved as a
kind of proxy for computing coverage at the package call level.  Does
this sound at all practical?  If so, can you see any relatively easy
way to extract this information from a running FriCAS image before and
after the execution of the test suite?

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Reply via email to