summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLars Wirzenius <liw@liw.fi>2020-01-05 15:41:58 +0200
committerLars Wirzenius <liw@liw.fi>2020-01-05 15:41:58 +0200
commit083db5a470bfaa76dfd9381c42f9c3d52b371050 (patch)
tree95fd35b11d1a6358e6edcb4e33fcbe65a5f1b0e9
parentdd207003abf1071c40ec7f93736aff0602775051 (diff)
downloadsubplot.liw.fi-083db5a470bfaa76dfd9381c42f9c3d52b371050.tar.gz
Publish log entry
-rw-r--r--blog/2020/01/05/data_files_for_tests.mdwn60
1 files changed, 60 insertions, 0 deletions
diff --git a/blog/2020/01/05/data_files_for_tests.mdwn b/blog/2020/01/05/data_files_for_tests.mdwn
new file mode 100644
index 0000000..3885a4a
--- /dev/null
+++ b/blog/2020/01/05/data_files_for_tests.mdwn
@@ -0,0 +1,60 @@
+[[!meta title="Data files for tests"]]
+[[!tag pondering]]
+[[!meta date="2020-01-05 15:30"]]
+
+I've started to sketch out the first Subplot document for Subplot.
+The goal is to have Subplot to test itself. The approach is to run the
+program with specific inputs, and examine the results. The inputs will
+be the Markdown, YAML, and Python files that Subplot needs to do its
+thing. This raises the question how those files should be stored. A
+few possible approaches:
+
+1. Provide the files adjacent to the subplot.md file that is the
+ Subplot self-testing file. This would mean the acceptance tests use
+ test data that's not evident in the output document of Subplot,
+ making them hard to examine unless one has access to the document
+ source code.
+
+1. Embed the file data into the scenarios. This is what Subplot's
+ predecessor yarn did. It tends to result in tediously long
+ scenarios. Tedious to read, tedious to write, tedious to change. On
+ the other hand, this would make the test data evident and not
+ require changes to current Subplot code.
+
+1. Embed the file data in the Markdown document, and have Subplot
+ extract it for the generated test program. This would require
+ changing Subplot to support that, but seems otherwise ideal.
+ Markdown, as implemented Pandoc, is fairly good at this, and Pandoc
+ can even do syntax highlighting if, for example, the data is in a
+ YAML format.
+
+I'm leaning strongly towards the last approach. It seems like the best
+approach for editing comfort, while keeping the test data evident to
+all stakeholders.
+
+The syntax would look something like below, which is an example of a
+test data file containing a Subplot document.
+
+~~~~markdown
+~~~{.file .markdown numberLines}
+---
+title: Test scenario
+bindings: b.yaml
+functions: f.py
+...
+
+# Simple
+This is the simplest possible test scenario
+
+```subplot
+given precondition foo
+when I do bar
+then bar was done
+```
+~~~
+~~~~
+
+Pandoc allows attributes to fenced code blocks. Above, we declare the
+block is a file, in markdown, and its lines should be numbered.
+Subplot would require the `.file` attribute to recognize it as a file.
+The rest are optional, but make Pandoc typeset the file nicely.