From: Junio C Hamano <gitster@pobox•com>
To: Kristoffer Haugsbakk <code@khaugsbakk•name>
Cc: git@vger•kernel.org, stolee@gmail•com
Subject: Re: [PATCH 0/8] t7900: untangle test dependencies
Date: Tue, 17 Oct 2023 12:59:38 -0700 [thread overview]
Message-ID: <xmqqbkcxhvf9.fsf@gitster.g> (raw)
In-Reply-To: <cover.1697319294.git.code@khaugsbakk.name> (Kristoffer Haugsbakk's message of "Sat, 14 Oct 2023 23:45:51 +0200")
Kristoffer Haugsbakk <code@khaugsbakk•name> writes:
> #!/bin/sh
> cd t
> # Every test run together with `setup` should pass
> for i in $(seq 1 42)
> do
> ./t7900-maintenance.sh --quiet --run=setup,$i || return 1
> done &&
It is kind-of surprising that with only 8 patches you can reach such
a state, but ...
> # The tests that used to depend on each other should still pass
> # when run together
> ./t7900-maintenance.sh --quiet --run=setup,30,31 &&
... this puzzles me. What does it mean for tests to "depend on each
other"? Does this mean running #31 with or without running #30 runs
under different condition and potentially run different things?
One might argue that, in an ideal world, our tests should work when
any non-setup tests are omitted (so, instead of $i above, you'll
have an arbitrary subsequence of 1..42 and your tests still pass),
and it may be a worthy goal, but at the same time, it may be a bit
impractical, as setting things up is costly, but what you can do in
the common "setup" will be very small. Or you'll have so much
"recovering from damage" in test_when_finished for each test that
makes such untangling of dependencies too costly.
next prev parent reply other threads:[~2023-10-17 19:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-14 21:45 [PATCH 0/8] t7900: untangle test dependencies Kristoffer Haugsbakk
2023-10-14 21:45 ` [PATCH 1/8] t7900: remove register dependency Kristoffer Haugsbakk
2023-10-14 21:45 ` [PATCH 2/8] t7900: setup and tear down clones Kristoffer Haugsbakk
2023-10-17 20:13 ` Junio C Hamano
2023-10-17 20:20 ` Kristoffer Haugsbakk
2023-10-14 21:45 ` [PATCH 3/8] t7900: create commit so that branch is born Kristoffer Haugsbakk
2023-10-14 21:45 ` [PATCH 4/8] t7900: factor out inheritance test dependency Kristoffer Haugsbakk
2023-10-14 21:45 ` [PATCH 5/8] t7900: factor out common schedule setup Kristoffer Haugsbakk
2023-10-14 21:45 ` [PATCH 6/8] t7900: fix `pfx` dependency Kristoffer Haugsbakk
2023-10-14 21:45 ` [PATCH 7/8] t7900: fix `print-args` dependency Kristoffer Haugsbakk
2023-10-14 21:45 ` [PATCH 8/8] t7900: factor out packfile dependency Kristoffer Haugsbakk
2023-10-14 23:00 ` [PATCH 9/8] t7900: fix register dependency Kristoffer Haugsbakk
2023-10-15 3:04 ` [PATCH 0/8] t7900: untangle test dependencies Jeff King
2023-10-17 19:59 ` Junio C Hamano [this message]
2023-10-17 20:14 ` Kristoffer Haugsbakk
2023-10-17 20:49 ` Junio C Hamano
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=xmqqbkcxhvf9.fsf@gitster.g \
--to=gitster@pobox$(echo .)com \
--cc=code@khaugsbakk$(echo .)name \
--cc=git@vger$(echo .)kernel.org \
--cc=stolee@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox