From: Felix Lechner via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org>
To: Josselin Poiret <dev@jpoiret.xyz>
Cc: "Dr. Arne Babenhauserheide" <arne_bab@web.de>,
Guix Devel <guix-devel@gnu.org>
Subject: Towards generalized testing (Was: Caching test results separately?)
Date: Mon, 13 Mar 2023 16:10:44 -0700 [thread overview]
Message-ID: <CAFHYt543LX3CZ-ZO8xVjH_GZMT6CcAWumMoN4mpWf9Jz1B3+MA@mail.gmail.com> (raw)
In-Reply-To: <871qlsi97h.fsf@jpoiret.xyz>
Hi Josselin,
On Mon, Mar 13, 2023 at 3:21 PM Josselin Poiret <dev@jpoiret.xyz> wrote:
>
> I would really like for tests to move out of build phases
>
> That would require a huge change to Guix though
Fortunately, there is a great precedent for that work in Debian. It is
called autopkgtest. [1]
One package I maintained there, called Lintian, had a comprehensive
test suite that mimicked large parts of Debian including building
packages. When I moved the tests out of the build process, it
shortened the build time from six hours to seven minutes.
That was on Gitlab with external runners provided by a donor.
The key to understanding Debian's autopkgtest process is that, while
the test suites are distributed together with the sources, they
actually test the *installed* versions of the software (which are
loaded separately). That crucial distinction catches important
user-facing errors that were previously undetectable, such as
installation in the wrong path.
We already have many good starting points in Guix. Some truly great
work has been done. [2]
There are also two SRFIs [3][4] although I am personally biased toward
TAP (the "Test-Anything Protocol") [5] and already used that in one of
my Guile modules. [6]
Either way, such testing efforts will make our distribution even
better, especially as we support additional architectures. I would be
eager to cooperate if there is an extra seat at the table.
Kind regards,
Felix
[1] https://people.debian.org/~eriberto/README.package-tests.html
[2] https://luis-felipe.gitlab.io/guile-proba/manual/
[3] https://srfi.schemers.org/srfi-64/srfi-64.html
[4] https://srfi.schemers.org/srfi-78/srfi-78.html
[5] https://codeberg.org/ft/guile-tap
[6] https://codeberg.org/lechner/guile-naptcha/src/branch/history/scm/test/naptcha/pseudo-random.scm
next prev parent reply other threads:[~2023-03-13 23:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-13 18:31 Caching test results separately? Dr. Arne Babenhauserheide
2023-03-13 22:21 ` Josselin Poiret
2023-03-13 22:44 ` Ryan Prior
2023-03-13 23:10 ` Felix Lechner via Development of GNU Guix and the GNU System distribution. [this message]
2023-03-14 11:03 ` Simon Tournier
2023-03-16 14:08 ` Ludovic Courtès
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFHYt543LX3CZ-ZO8xVjH_GZMT6CcAWumMoN4mpWf9Jz1B3+MA@mail.gmail.com \
--to=guix-devel@gnu.org \
--cc=arne_bab@web.de \
--cc=dev@jpoiret.xyz \
--cc=felix.lechner@lease-up.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).