Types
Unexpected comes with a type system that is used to explain how different types are compared, diffed, inspected and is also used to limit the scope of assertions.
The following types are provided by out of the box by Unexpected:
any, arguments, array, array-like, binaryArray, boolean,
Buffer, date, Error, function, Int8Array, Int16Array,
Int32Array, NaN, null, number, object, regexp, string,
Uint8Array, Uint16Array, Uint32Array, and undefined.
expect.addType(typeDefinition)
Unexpected can be extended with knowledge about new types by calling
the addType method with a type definition. The type definition must
implement the required parts of the following interface:
Required members:
- name:
String- the name of the type. - identify:
boolean function(value)- a function deciding if the type should be used for the given value.
Note that your type has the option to take precedence over all the built-in
types. Test subjects will be tested against the most recently defined type
first, so identify functions should take care not to break with undefined,
null and so on.
Optional members:
- base:
String- the name of the base type. Defaults toany. - equal:
boolean function(a, b, equal)- a function capable of comparing two values of this type for equality. If not specified it is inherited from the base type. - inspect:
function(value, depth, output, inspect)- a function capable of inspecting a value of this type. If not specified it is inherited from the base type. - diff:
comparison function(actual, expected, output, diff, inspect)- a function producing a comparison between two values of this type. If not specified it is inherited from the base type.
Example
Adding new types to the system is best explained by an example. Let's
say we wanted to add first class support for a Person type:
We start out by creating a basic type for handling Person
instances. The name of the type should be Person and it should
inherit from the built-in object type. Furthermore we add an
identify method that will recognize Person instances.
When you specify a base type, you inherit the optional members you
didn't implement. In this case we inherited the methods equal,
inspect and diff from the object type.
Imagine that we make a failing expectation on a Person instance:
That is already quite helpful, but it would be even nicer if the
stringification of Person instances could read as valid calls to the
constructor. We can fix that by implementing an inspect method on the type.
Now we get the following output:
That is a bit better, let me explain how it works. The inspect
method is called with the value to be inspected, the depth this type
should be inspected with, an output the inspected value should be
written to, and an inspect function that can be used to recursively
inspect members. The output is an instance of
magicpen extended with a
number of styles.
We write new Person( without styling, then we append the inspected
name, write a ,, inspect the age and finish with the closing
parenthesis. When inspect is called without a depth parameter it
defaults to depth-1. Values inspected with depth zero will be
inspected as .... In this case we always want the name so we forward the
same depth to the inspect function.
Let's say we wanted Person instances only to be compared by name and not by
age. Then we need to override the equal method:
This will produce the same output as above, but that means the diff if wrong. It states that the age should be changed. We can fix that the following way:
The above diff method just calls the diff method on the base type
with objects that only contain the name. The object diff will take
care of all the hard work. We could also have called the diff
function we got as an argument, but that will go off detecting the
types of the parameters, therefore it is faster to call diff method
on the base directly when you know it is the one you need.
You could also do something really custom as seen below:
That would produce the following output.
This is a rather complicated example and I won't go though the details,
but I would like to comment on the inline flag. When we diff objects
against each other, the values of the keys will be diffed against each
other. That means diffs are inserted into the containing
structure. You can control this behavior using the inline flag. If
the child diff is inline, it means that it will be appended directly
into the parent; otherwise the diff will be inserted in an annotation
block. The outputs below shows the contrast between setting the
Person diff to inline or not.
Now that we have implemented a type, we can start adding assertions to it. These assertions will only work on this type or types inheriting from the type.
Because Person inherits from object you can use all assertion
defined for object or any of its ancestors. Here is an example:
The best resource for learning more about custom types is to look at how the predefined types are built: