itl.core — coreagile/itl 0.2.4

add-op! clj

add-proc! clj

apply-generated-assertion clj

(apply-generated-assertion asserts page-state emsg k)

assemble-generated-cell clj

(assemble-generated-cell declarations
                         headers-to-keys
                         is-assert?
                         page-state
                         emsg
                         original
                         label)

basic-equivalence clj

(basic-equivalence v)

bit-bob-comparison clj

(bit-bob-comparison _)

Parses a string that contains a regular expression to be applied to a value

capture-output clj

(capture-output logfile f)

column-table clj

(column-table page-state {:keys [rows]} {:keys [assign exec asserts]})

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.

convert-missing clj

(convert-missing v)

defop clj macro

(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.

defproc clj macro

(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]

deftafn clj macro

(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

deftfn clj macro

(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.

exception clj

exec-file clj

(exec-file indir outdir {:keys [file] :as page-state})

Run a file on the classpath through the asciidoc parser/generator

execute-asciidoc clj

(execute-asciidoc initial-state in out)

Parse an Asciidoc 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 clj

(extract-by-key cells k)

fail clj

generate-cell clj

(generate-cell declarations generate asserts label)

generate-row clj

(generate-row page-state declarations generate exec asserts _)

generated-var clj

(generated-var page-state var-code)

If the var-code looks like uuid>x we will generate a random UUID and store it in page-state at [:generated :x]. It will then return [page-state new-value]. If it looks like <x we will try and get [:generated :x] out of the page state and just return the value back. If it doesn't match these patterns, the var-code is returned.

generative-table clj

(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.

headers-to-keys clj

(headers-to-keys m)

integer-comparison clj

(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".

loop-of-strings clj

(loop-of-strings v)

pass clj

random-integer clj

(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.

random-ssn clj

(random-ssn _)

run clj

(run file)

(run file out-file)

Execute file. If out-file is specified, results will be written there. Otherwise they will be written to file without the .adoc and with .html. AKA: README.adoc -> README.html