Subject: [bug#49981] wip: Introduce unit-tests.

From: Maxim Cournoyer <[email-masked]>
Date: Mon, 30 Aug 2021 16:14:07 -0400

Hi Mathieu,

Mathieu Othacehe <[email-masked]> writes:

> Hello,
>
> I would like to convert the Guix tests in the "tests/" directory to
> derivations, in the exact same way as for the system tests in the
> "gnu/tests/" directory.

Perhaps it's because I spent some effort into improving our (srfi
srfi-64) based test runner, but I have some reserves about the proposed
change, that echoes what Chris and others have mentioned.

1. More in the way between the tests and the code, which may complicate
test debugging.  Unit tests are supposed to involve as little as
possible, ideally; getting the daemon and the store for even the most
trivial tests seems undesirable.

2. One gripe that I have for the check-system tests is that for flaky
tests, if they pass, the success is cached (it's a derivation) and
there's no easy way to re-run them.  I wouldn't want that property to
now apply to unit tests as well.

> For that, I propose to introduce a new <unit-test> record. This would
> allow us to select all the unit tests using the "all-unit-tests"
> procedure, and add them to the (gnu ci) module.

I'm not sure if that's a convenient API for the CI, but our unit test
runner has had the [--select=REGEXP] and [--exclude=REGEXP] command line
switches for a while, that provides the ability to select or exclude
specific tests (at their individual level).

> This way, we could have a Cuirass specification for the unit tests, as
> we already have for the system tests, to spot regressions early on.

Is there something with the current scheme that prevents us from doing
so already?

> Here's a patch that translates the "account.scm" test module to the new
> proposed mechanism. If there are no objections, I plan to convert all
> the remaining tests.

I guess mine is an objection :-).  But with more explanations perhaps I
can better understand things.

Thanks,

Maxim