+title: The truth about veritas
+tagline: Introduction to a new testing facility
+ url: http://bitbucket.org/certainty/veritas
+It's been a while since I wrote about my failure with [missbehave](http://lisp-unleashed.de/2013/06/19/i_did_missbehave). I mentioned that I was working on a successor that aims to fix the all
+the things that have been wrong with missbehave.
+I've had a little bit of time to work on that new library and it's getting shape, so i figured that it might be a good idea to tell you a little bit about it.
+## Why yet another testing library?
+Let me get one thing straight out of the way. If you want a battle-tested and extremely well designed, well thoughtout and configurable testing library that has minimal dependencies, please go with Alex Shinn's [test](http://wiki.call-cc.org/eggref/4/test). It's awesome, really! I drew much inspiration from it and I keep being impressed about its elegance.
+Why did I start over and continued my journey to write my own testing library. The main reasons
+are that I learn alot from it, that it gives me the opportunity to work with my favorite scheme
+and lastly because I wanted to try other approaches to testing that eventually address a few of
+the very few shortcomings of the [test egg](http://wiki.call-cc.org/eggref/4/test).
+The following introduces you to veritas and outlines its basic functionality along
+with a description about some internals.
+One of the problems with missbehave was that it was basically a monolithic library that conflated
+many concerns. In veritas I had to address this. I wanted to have a very basic and tiny core that can be used on its own to have minimal dependencies, but also I wanted the ability to build
+more comfort around that core. I identified and isolated a few concerns that a testing library has to address.
+The core is basically a driver that knows how to run a verification and notify events. It does
+a little bit more to take care of errors that accuring during the verification process but
+apart from that it really just is the instrumentation unit that wires together the parts.
+The core also provides the basic syntactic constructs that are used to describe verifications.
+This is the form that you use to describe your verifications. It allows you to apply a given
+verifier to a subject. It comes in different variations:
+This uses the builtin boolean verifier that succeeds if the subject passed to it evaluates to
+true and fails otherwise.
+ (verify subject (is expected))
+This form applies the is-verifier to the subject. It will succeed if it matches the expected
+value equals the subject. This is just an example of the basic pattern that involves a verifier.
+ (verify subject (is expectey) "This is my description")
+This form is the same as the form before but also adds a description to that verification.
+This really just sets the description meta-data for that verification.
+Reporters my chose to take it and use it to do some nice reporting.
+This is just verify with negated logic. It will succeed when a corresponding verify would have
+failed. It's there to be more explicit about negated verifictions which might become cumbersome
+to read. It supports all the variations of the verify form.
+If you want to group verifications you can do this with the group macro.
+ (group "This is my group of tests"
+ (verify (length "string") (is > 0))
+ (verify (reverse "string") (is "gnirts")))
+This will add the group name to the meta-data of each verification that is within that group.
+If you don't want to append a description string to a verification you can wrap it into a
+ (describe "This is my verification"
+This will add the description to the meta-data of each verification it contains.
+Each verification can have meta-data attached to it. It's used by the core to ammend
+verifications with for example descriptions. However it can und shall be used by the client
+also to have a means to attach data to tests. Eventlisteners have access to that meta-data
+and can use it to do all sorts of interesting things.
+ (meta (bug: "#1234" focus: #t)
+As you see meta data is a key-value list that works much like an assocition list but has
+fewer parens. It uses keywords as keys. The value can be an abritary scheme value.
+Meta-data can be nested and the each level of nesting will inherit the meta-data from
+outer levels. Also you can overwrite meta-data from outer levels in inner levels.
+It just works as you'd expect it to work.
+ (meta (bugs: #t slow: #t)
+ (meta (id: "#1234" slow: #f fast: #t)
+ ;; slow is temporarily set to #f
+ ;; also this verification inherits the bugs: meta-data
+Veritas core doesn't need to know how to do the reporting. That's totally up to
+another part that may or may not declare interest in the verification events. The following events are notified:
+* Start of a verification
+* A verification has succeeded
+* A verification has failed
+* A verification is pending
+You can add your own listener to each of these events. Also every event can of course
+have multiple listeners which are all invoked.
+### Testing with random input
+#### Pretty output at the console