tests: parse go-testmark's testdata files.
commit 5bcf631fcbb5a5e1c3c6006ea3bcf6092ed55089 · parent 4469ad6c39
· browse this tree
Ximianth, 2026-10-23 09:44:24 UTC
Copied from go-testmark's testdata/ at 99d84c8 (same author, same license).
diff --git a/tests/test-testdata.sh b/tests/test-testdata.sh new file mode 100755 index 0000000..354087f --- /dev/null +++ b/tests/test-testdata.sh @@ -0,0 +1,49 @@ +#!/bin/bash +## go-testmark's testdata files, parsed whole. +set -euo pipefail +cd "$(dirname "$0")" +# shellcheck source=tests/lib.sh +source ./lib.sh +cd "$TESTDATA" # so error messages carry the short relative path + +dump_parse example.md >"$work/got" +expect_eq "example.md" "$(<"$work/got")" "$( + cat <<-'EOF' + hunk "this-is-the-data-name" + info "text" + body "the content of this code block is data which can be read,\nand *replaced*, by testmark.\n" + hunk "more-data" + info "go" + body "func OtherMarkdownParsers() (shouldHighlight bool) {\n\treturn true\n}\n" + hunk "cannot-describe-no-linebreak" + info "" + body "A markdown codeblock always has a trailing linebreak before its close indicator, you see.\n" + EOF +)" + +dump_parse exampleWithDirs.md >"$work/got" +expect_eq "exampleWithDirs.md" "$(<"$work/got")" "$( + cat <<-'EOF' + hunk "one/two" + info "text" + body "foo\n" + hunk "one/three" + info "text" + body "bar\n" + hunk "one" + info "text" + body "baz\n" + hunk "really/deep/dirs/wow" + info "text" + body "zot\n" + hunk "one/four/bang" + info "text" + body "mop\n" + EOF +)" + +dump_parse exampleWithDuplicateHunks.md >"$work/got" +expect_eq "exampleWithDuplicateHunks.md" "$(<"$work/got")" \ + 'error: testmark: exampleWithDuplicateHunks.md:12: duplicate hunk name "one/two/three"' + +exit "$RESULT" diff --git a/tests/testdata/example.md b/tests/testdata/example.md new file mode 100644 index 0000000..d69d5d7 --- /dev/null +++ b/tests/testdata/example.md @@ -0,0 +1,75 @@ +this is a markdown file +======================= + +... and it's also going to contain test fixture data. + +The markdown is full of idioms and unidiomatic things alike. + +The contents don't really matter, mostly. +They're freetext, and you can use markdown to describe whatever you want. + +Except these: + +[testmark]:# (this-is-the-data-name) +```text +the content of this code block is data which can be read, +and *replaced*, by testmark. +``` + +That's not a regular code block. +I mean, it is -- but be sure to look at this file in a "raw" mode. +There's also a comment above it, which tells testmark to look at it: + +``` +[testmark]:# (this-is-the-data-name) +``` + +That comment, coming right before a triple-backtick code block, is a signal. +It tells testmark to look at the codeblock, and also gives that code block a name. + + +Multiple data hunks per file +---------------------------- + +You can have more than one block like that in a file: + +[testmark]:# (more-data) +```go +func OtherMarkdownParsers() (shouldHighlight bool) { + return true +} +``` + +### the headings don't matter + +Every other markdown feature, like the headings, are totally ignored. +That structure is for *you*, human, as you write documentation together with your data. + + +Editing +------- + +Testmark can edit a file like this one, and replace the code block contents according to the name given in the comment. +(It's kind of like a big map of strings, in that regard.) + +Usually, a human writes the testmark file. +If the human wants to programmatically populate things, the human writes out the code block and names it with the magic comment format, +and then runs some tool that updates the content. + +Some libraries may also be able to create a testmark file purely programmatically, but this is usually more complicated, +and makes it harder to control the rest of the document... +which, presumably, you do still want to fill with prose (and markdown-formatted) descriptions of the data. + + +One note +-------- + +There is one thing this format is bad at: +you can't easily describe data that doesn't have a trailing linebreak. + +[testmark]:# (cannot-describe-no-linebreak) +``` +A markdown codeblock always has a trailing linebreak before its close indicator, you see. +``` + +That's a problem in many formats though, frankly. diff --git a/tests/testdata/exampleWithDirs.md b/tests/testdata/exampleWithDirs.md new file mode 100644 index 0000000..92efb59 --- /dev/null +++ b/tests/testdata/exampleWithDirs.md @@ -0,0 +1,42 @@ +an example with "directories" +============================= + +This testmark implementation provides convenience functions for treating +the data hunk names as if they were "paths" in some sort of "filesystem". + +So, in this file we'll exercise that by using a bunch of hunk names that have slashes in them. + +### directories can be implied + +[testmark]:# (one/two) +```text +foo +``` + +[testmark]:# (one/three) +```text +bar +``` + +### a path can have both children and data + +(Maybe avoid leaning on this, though, because some would argue it's weird.) + +[testmark]:# (one) +```text +baz +``` + +### directories can be implied deeply + +[testmark]:# (really/deep/dirs/wow) +```text +zot +``` + +### files in the same directory don't have to be subsequent + +[testmark]:# (one/four/bang) +```text +mop +``` diff --git a/tests/testdata/exampleWithDuplicateHunks.md b/tests/testdata/exampleWithDuplicateHunks.md new file mode 100644 index 0000000..c2b5cab --- /dev/null +++ b/tests/testdata/exampleWithDuplicateHunks.md @@ -0,0 +1,15 @@ +an example with duplicate hunk names +==== + +Duplicate hunk names are invalid and will cause parse to return an error. + + +[testmark]:# (one/two/three) +```text +foo +``` + +[testmark]:# (one/two/three) +```text +bar +```