all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: Mathieu Othacehe <othacehe@gnu.org>
Cc: 49981@debbugs.gnu.org
Subject: [bug#49981] wip: Introduce unit-tests.
Date: Mon, 30 Aug 2021 16:14:07 -0400	[thread overview]
Message-ID: <87czpulmgg.fsf@gmail.com> (raw)
In-Reply-To: <87o8a5734b.fsf@gnu.org> (Mathieu Othacehe's message of "Tue, 10 Aug 2021 17:04:20 +0200")

Hi Mathieu,

Mathieu Othacehe <othacehe@gnu.org> 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




  parent reply	other threads:[~2021-08-30 20:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-10 15:04 [bug#49981] wip: Introduce unit-tests Mathieu Othacehe
2021-08-10 18:15 ` Christopher Baines
2021-08-12 14:50   ` Mathieu Othacehe
2021-08-10 18:23 ` Maxime Devos
2021-08-30 20:14 ` Maxim Cournoyer [this message]
2021-08-31  6:27   ` zimoun
2021-08-31  6:36 ` zimoun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87czpulmgg.fsf@gmail.com \
    --to=maxim.cournoyer@gmail.com \
    --cc=49981@debbugs.gnu.org \
    --cc=othacehe@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.