(add-generator! n f)
(add-var page-state k v)
Add a new variable to the page state for use in column table assignments and expectations.
Add a new variable to the page state for use in column table assignments and expectations.
(apply-generated-assertion asserts page-state emsg k)
(assemble-generated-cell declarations
headers-to-keys
is-assert?
page-state
emsg
original
label)
(async-column-table page-state rows assign exec asserts)
(basic-equivalence v)
(bit-bob-comparison _)
Parses a string that contains a regular expression to be applied to a value
Parses a string that contains a regular expression to be applied to a value
(capture-output logfile f)
(column-table page-state
{:keys [rows]}
{:keys [assign exec asserts]}
&
{:keys [parallel?]})
Take a table of data and assert a bunch of stuff on it. The
assign
map should contain mappings from labels in the table to
keys they should be mapped to in the page-state
collection. The exec
should be a single function to be executed for each row. It will receive the
current state after having all the assignments made. It should return
the state to be passed to the assertions, and eventually, the next row.
Finally, the assert
should contain yet another map of labels to keys in the
state that should match.
If any content in the parsed document is either assigned or asserted against
and contains {{x}}
syntax, the value of :x
will be pulled from
page variables and inserted in its place. See add-var
for more information.
If you pass :parallel? true
at the end, each row will be executed in
parallel, and its page state will not be passed to the next row. The
original state that was passed into this function will be returned out.
Take a table of data and assert a bunch of stuff on it. The `assign` map should contain mappings from labels in the table to keys they should be mapped to in the `page-state` collection. The `exec` should be a single function to be executed for each row. It will receive the current state after having all the assignments made. It should return the state to be passed to the assertions, and eventually, the next row. Finally, the `assert` should contain yet another map of labels to keys in the state that should match. If any content in the parsed document is either assigned or asserted against and contains `{{x}}` syntax, the value of `:x` will be pulled from page variables and inserted in its place. See `add-var` for more information. If you pass `:parallel? true` at the end, each row will be executed in parallel, and its page state will not be passed to the next row. The original state that was passed into this function will be returned out.
(convert-missing v)
(defgenerator n & body)
Defines a function that generates a value, which will eventually be bound to
a variable. The name may only contain letters and dashes. The function must
not take any parameters. See generated-var
Defines a function that generates a value, which will eventually be bound to a variable. The name may only contain letters and dashes. The function must not take any parameters. See `generated-var`
(defop n [page-state] & body)
Defines an operation that can be executed in your test. Accepts a
name (n
) that will be referred to in brackets in the document. The body
will be of a function that accepts a single parameter page-state
.
That parameter will be filled in with the current state of the running tests.
An example op reference in your doc could be: op::[do something]
Your operation must return whatever parts of page-state
your operation
wishes to pass on to future operations and/or assertions.
Defines an operation that can be executed in your test. Accepts a name (`n`) that will be referred to in brackets in the document. The body will be of a function that accepts a single parameter `page-state`. That parameter will be filled in with the current state of the running tests. An example op reference in your doc could be: `op::[do something]` Your operation *must* return whatever parts of `page-state` your operation wishes to pass on to future operations and/or assertions.
(defproc n [page-state args] & body)
Defines a procedure that can be executed in your test. Accepts a
name n
and a set of bindings page-state
and aargs
. Just as in defop
,
the state will be bound to page-state
and must be passed back out of your
proc with whatever changes need to be made. a
will be bound to the
a map of arguments. Check out
http://www.methods.co.nz/asciidoc/chunked/ch21.html for more info.
Example proc reference in your doc: exec:say[msg=hello]
Defines a procedure that can be executed in your test. Accepts a name `n` and a set of bindings `page-state` and `aargs`. Just as in `defop`, the state will be bound to `page-state` and must be passed back out of your proc with whatever changes need to be made. `a` will be bound to the a map of arguments. Check out <http://www.methods.co.nz/asciidoc/chunked/ch21.html> for more info. Example proc reference in your doc: `exec:say[msg=hello]`
(deftafn n [page-state table-data args] & body)
Just like deftfn
, except this table also accepts arguments passed in
from the source document as args
Just like `deftfn`, except this table also accepts arguments passed in from the source document as `args`
(deftfn n [page-state table-data] & body)
Defines a table processing function. Accepts a name n
that will be
referred to in brackets in the table's legend. The body will be of a
function that accepts two parameters: page-state
, the current state of the
running tests, and table-data
, a structure containing the parsed table
structure.
Your operation must return a vector containing an updated
[page-state table-data]
. The value of page-state
will be sent to the next
operation, whereas table-data
will be re-constituted into a table and
inserted into the document content.
Defines a table processing function. Accepts a name `n` that will be referred to in brackets in the table's legend. The body will be of a function that accepts two parameters: `page-state`, the current state of the running tests, and `table-data`, a structure containing the parsed table structure. Your operation must return a vector containing an updated `[page-state table-data]`. The value of `page-state` will be sent to the next operation, whereas `table-data` will be re-constituted into a table and inserted into the document content.
(exec-file indir outdir {:keys [file] :as page-state})
Run a file on the classpath through the asciidoc parser/generator
Run a file on the classpath through the asciidoc parser/generator
(execute execute-fn status-fn initial-state in out)
Parse a document on in
that contains bindings, assertions, and/or
operations, executing them, and writing the modified markdown into the given
out
. The initial-state
is a map of bindings that the document can use.
Parse a document on `in` that contains bindings, assertions, and/or operations, executing them, and writing the modified markdown into the given `out`. The `initial-state` is a map of bindings that the document can use.
(extract-by-key cells k)
(generate-cell declarations generate asserts label)
(generate-row page-state declarations generate exec asserts _)
(generated-var page-state var-code)
If the var-code looks like uuid>x
we will look for a generator bound to
"uuid" and store its result in page-state
at [:generated :x]
. It will
then return [page-state assigned-var new-value]
.
Otherwise, [page-state nil var-code]
will be returned.
See defgenerator
If the var-code looks like `uuid>x` we will look for a generator bound to "uuid" and store its result in `page-state` at `[:generated :x]`. It will then return `[page-state assigned-var new-value]`. Otherwise, `[page-state nil var-code]` will be returned. See `defgenerator`
(generative-table page-state
{[declarations] :rows}
{:keys [generate exec asserts]}
num-rows)
Take a table with two rows and generate a bunch more rows suitable for for assertion. The first row is the names of the columns of each of the newly generated rows. The second row is the specifications by which we generate or assert against values.
Take a table with two rows and generate a bunch more rows suitable for for assertion. The first row is the names of the columns of each of the newly generated rows. The second row is the specifications by which we generate or assert against values.
(headers-to-keys m)
(integer-comparison v)
Parses a string that contains an operator and an operand to be applied to two values. Produces a function which takes two values and produces the string value "true" if the operand applied successfully, else "false".
Parses a string that contains an operator and an operand to be applied to two values. Produces a function which takes two values and produces the string value "true" if the operand applied successfully, else "false".
(loop-of-strings v)
(random-integer v)
Parses a string that contains two integers separate by 3 dots (e.g. "1...50") and produces a random number within that range, inclusive of the first integer, and exclusive of the second.
Parses a string that contains two integers separate by 3 dots (e.g. "1...50") and produces a random number within that range, inclusive of the first integer, and exclusive of the second.
(random-ssn _)
(run file)
(run file out-file)
(run execute-fn status-fn file out-file)
Execute file
. If out-file
is specified, results will be written there.
Otherwise they will be written to file
replacing the extension with
.html
. AKA: README.adoc -> README.html
Execute `file`. If `out-file` is specified, results will be written there. Otherwise they will be written to `file` replacing the extension with `.html`. AKA: `README.adoc -> README.html`
(sync-column-table page-state rows assign exec asserts)
(vars page-state)
Retrieve a list of all vars in the given page-state
Retrieve a list of all vars in the given `page-state`
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close