On Mon, Jul 01, 2024 at 08:51:44PM -0400, Jeff King wrote:
> Obviously we'd want to add to the chainlint tests here. It looks like
> the current test infrastructure is focused on evaluating snippets, with
> the test_expect_success part already handled.
So doing this (with the patch I showed earlier):
diff --git a/t/Makefile b/t/Makefile
index b2eb9f770b..7c97aa3673 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -106,18 +106,28 @@ clean: clean-except-prove-cache
clean-chainlint:
$(RM) -r '$(CHAINLINTTMP_SQ)'
+CHAINLINTTESTS_SRC = $(patsubst %,chainlint/%.test,$(CHAINLINTTESTS))
check-chainlint:
@mkdir -p '$(CHAINLINTTMP_SQ)' && \
for i in $(CHAINLINTTESTS); do \
echo "test_expect_success '$$i' '" && \
sed -e '/^# LINT: /d' chainlint/$$i.test && \
echo "'"; \
done >'$(CHAINLINTTMP_SQ)'/tests && \
+ for i in $$(grep -L "'" $(CHAINLINTTESTS_SRC)); do \
+ echo "test_expect_success '$$i' - <<\\\\EOT" && \
+ sed -e '/^# LINT: /d' $$i && \
+ echo "EOT"; \
+ done >>'$(CHAINLINTTMP_SQ)'/tests && \
{ \
echo "# chainlint: $(CHAINLINTTMP_SQ)/tests" && \
for i in $(CHAINLINTTESTS); do \
echo "# chainlint: $$i" && \
cat chainlint/$$i.expect; \
+ done && \
+ for i in $$(grep -L "'" $(CHAINLINTTESTS_SRC)); do \
+ echo "# chainlint: $$i" && \
+ cat $${i%.test}.expect; \
done \
} >'$(CHAINLINTTMP_SQ)'/expect && \
$(CHAINLINT) --emit-all '$(CHAINLINTTMP_SQ)'/tests | \
does pass. It's just running all of the tests inside an "EOT" block. But
we have to omit ones that have single quotes in them, because they are
making the implicit assumption that they're inside a single-quoted block
(so they do things like '"$foo"', or '\'', etc, which behave differently
in a here-doc).
It was a nice check that the output is the same in both cases, but it's
a bit limiting as a test suite, as there's no room to introduce test
cases that vary the test_expect_success lines. I'm thinking the path
forward may be:
1. Move the test_expect_success wrapping lines into each
chainlint/*.test file. It's a little bit of extra boilerplate, but
it makes them a bit easier to reason about on their own.
2. Add a few new tests that use here-docs with a few variations
("<<EOT", "<<\EOT", probably a here-doc inside the test here-doc).
Does that sound OK to you?
-Peff
