fesor/json_matcher

Library for simplifying data verification in functional tests for your JSON-based APIs

json_matcher's Issues

Use exceptions on matching

Now matchers returns bool values, so user should handle assertions something like

assert($my($response)->equal($json));

Also this will allow to use matchers chaining:

$my($response)
   ->includes($user1, ['at' => 'friends'])
   ->notIncludes($user2, ['at' => 'friends'])
   ->haveSize(2, ['at' => 'friends'])
   ->equal($user1Id, ['at' => 'friends/0/id']
;

Allow to use hash tables as subsets of data

Given we have json:

{
   "foo": 1,
   "bar": 2,
   "baz": 3
}

Matchers should allow to check that json includes subsets:

{"baz": 3, "foo": 1}

Json Schema validation

Json Schema is very powerful tool to verify JSON responses. But it not so user friendly and very verbose. Custom schema definitions and refs makes life a little bit easier but not so much.

I like the way type declarations made in RAML 1.0. It has a lot of sugar, it allows users to define user types, extending primitives. So we need to implement something like this:

// register custom type
JsonMatcher\Types::register('email', [
    'pattern' => '^.+\@\S+\.\S+'
]);

// or register multiple types:
JsonMatcher\Types::register([
    'integer' => [
         'type' => 'number',
         'multipleOf' => 1.0
    ],
    'positiveInteger' => [
         'type' => 'integer',
         'minimum' => 0,
         'exclusiveMinimum' => true
    ],
    'UserRegisterRequest' => [
         'properties' => [
              'email' => 'email',
              'password' => [
                   'minLength' => 4
              ],
              'first_name?' => 'string',
              'last_name?' => 'string'
         ]
    ],
]);

And then we can just use it:

$json->matches('UserRegisterRequest');
// or we can use inline type declarations
$json->matches([
    'type' => 'UserRegisterRequest',
    'properties' => [
        'foo' => 'string'
    ]
]);

Type expressions

Type expressions are fully stolen from RAML:

Type expressions provide a powerful way of referring to, and even defining, types. Type expressions can be used wherever a type is expected. The simplest type expression is just the name of a type. Using type expressions, you can devise type unions, arrays, maps, and other things.

Expression	Description
Person	The simplest type expression: A single type
Person[]	An array of Person objects
string[]	An array of string scalars
string[][]	A bi-dimensional array of string scalars
`string	Person`
`(string	Person)[]`

Replace exceptions with errors list

Instead of exceptions json matcher should use error list. This should simplify integration within testing frameworks. Related to #8

files support

There should be ability to match JSON with file contents. For example

$jsonResponse
    ->equalFile('my.json')
    ->includesFile('partial.json', ['at' => 'collection'])
;

Also files_dir options should be provided in matcher constructor.

hasPath matcher doesn't support negative matching.

Allow to transform assertions

For now all failed assertion just throws ugly exceptions. Some testing frameworks required special assertion mechanism to be used.

It will be cool to have some API for defining own assertion result.

Exclude all keys except

Sometime it is useful to check just several properties in some large JSON. We already have excluding and including options for this purposes, but we can also do something like:

$jsonResponse
    ->equal('{
         "foo": ["foo"],
         "bar": "bar"
    }', ['excluding' => 'all', 'except' => ['foo', 'bar'])
;

Fix misspelling in method names

• haveSize should be hasSize
• havePath should be hasPath
• ...

and so on

Use json_decode instead of seld\jsonlint