Common list test library.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Matt Skinner aec84fbd39 Added ignore for .idea file 1 year ago
doc Many refactoring and improvements. 2 years ago
src Many refactoring and improvements. 2 years ago
.gitignore Added ignore for .idea file 1 year ago
LICENSE Initial commit. 2 years ago
README.md Many refactoring and improvements. 2 years ago
generate-doc.lisp Many refactoring and improvements. 2 years ago
load.lisp Initial commit. 2 years ago
p.test.asd Many refactoring and improvements. 2 years ago

README.md

Test

This test library provides a means to write test cases that encapsulate assertions and tries to not stop customize test writing. If one wants to use behavioural driving testing techniques the developer is free to do so on top of this library. I is not the goal of this library to provide a high level test constructs except for cases where it might be common.

Additing an assertion

An assertion is an assumption that is expected to complain noisely if it is ever found to not be true. To add an assertion is fairly simple:


(defmacro! assert-< (o!x o!y)
  "Assert that a value is less than another value."
  `(when (not (< ,g!x ,g!y))
     (error 'assert-error :message (format nil "Expected (< ~A ~A)" ,g!x ,g!y) :forms (list ',o!x ',o!y))))

In this example we use defmacro! as a shorthand to avoid having to explictly handle the issue of multiple evaluation in macros and is from the Let Over Lambda book. Here we have arguments X and Y that are prefixed with o! (the letter o means “once”, as in only evaluate once) to denote that they map to their corresponding g! values (the letter g means “generated” as in created via gensym). Essentially all that needs to be remember is that o! arguments map to g! in the body.

We perform that logic that would fail the assertion. In this case it is the opposite of less than, greater than, and error a specific error type, making sure to supply the error message with the exact values that failed. We also give a quoted version of the forms to make it easier to understand where exactly in a test a failure occured. Also in data driven tests it may not be obvious which data point failed without having the forms included with the error message.