[bug#50967] [PATCH 00/12] Move (gnu home-services XYZ) to (gnu services XYZ)

[Ludovic Courtès]

Hi Oleg,

Oleg Pykhalov <go.wigust@gmail.com> skribis:

> From: Andrew Tropin <andrew@trop.in>
>
> * tests/guix-home.sh: New file.
> * Makefile.am (SH_TESTS): Add tests/guix-home.sh.
>
> Signed-off-by: Oleg Pykhalov <go.wigust@gmail.com>

[...]

> +# Reporting of syntax errors.
> +
> +cat > "$tmpfile"<<EOF
> +;; This is line 1, and the next one is line 2.
> +   (home-environment
> +    (packages))
> +;; The 'T' is at column 3.
> +EOF

This test is more or less copied from guix-system.sh, and I think it’s
not that useful because it’s testing the exact same functionality.

Would it be possible to have a CLI test that really tests ‘guix home’
functionality?

The difficulty is that this would tend to rebuild the world.  This can
be worked around in one of two ways:

  1. Add a ‘--bootstrap’ flag for force the use of the “guile-bootstrap”
     package instead of “guile”, for instance, as is done for
     tests/guix-package.sh.

  2. Run tests only when a “real” daemon is available, using it instead
     of the test daemon, as is done in tests/guix-pack-relocatable.sh.

  3. Run tests in a VM using the (gnu tests …) infrastructure.

I don’t think #1 would work well for Guix Home.  #2 is the easiest; the
downside is that tests would only be run on developer machines, not in
CI.  #3 is the most flexible approach, but the downside is that it’s
more resource-intensive (needs to build a VM image, etc.).

Overall, I’d recommend starting with #2 and eventually add tests as #3,
as far as integration tests are concerned.

Then again, it’s also possible to have focused unit tests for specific
pieces, just like we have tests/union.scm for instance.

WDYT?

Thanks,
Ludo’.