repocho/raml-mocker

Node module to create random responses to requests based on RAML rest definition.

raml-mocker's Issues

Formatters extension / discussion

I've been working, experimenting with and thinking about mocking (raml) API data. I've come to the conclusion that, although faker is nice, a lot nicer is chance.js. One of the reasons is the functions are a lot more sophisticated (but normalized, through option map arguments, normally they would be unary fns taking 0 or 1 argument).

The problem with the current architecture we have, mainly formats.js contains a literal mapping from our fns to fakers. Perhaps back then (I'm talking the ~v1 faker here) it was manageable due to the small amount of functions present but at the current time it is cumbersome to write them all for ourselves (in this library) as well as expect the user to do so.

I was inspired mostly by work done here: https://github.com/json-schema-faker/json-schema-faker/blob/master/lib/util/container.js

What I do not really like about their solution is that they use the schema keywords for each lib, so e.g. calling a faker function would take something like:

"faker" : "somefn"

and chance would take:

"chance" : "somefn"

I am not really sure how they pass arguments though. Personally, I'd think the following might be a (more, but I'm biased of course) elegant solution:

"mock" : {"func" : "faker.somefn.we.map.by.name",
          "args" : {"min": 40, "max": 120}}

Question is how one would want to expose this. I am not sure if raw (faker["somefn"]["we"]["map"]["by"]["name"]) access is a great idea but on the other hand, few harmful functions in those libraries. Pretty much all is geared towards, well duh, generating random data. Most are functions at about 1 level deep from the root of the main library exported object or function. Further limiting allowed selection (through JSON Schemas) to functions (as you already do the normal/lower-case check for functions) and allowing calls to root or first level nested functions could be mapped dynamically or, called directly via string reference (I guess the functional JS way would be to just split on the dots and reduce the properties from the object) as I demonstrated, using square bracket notation.

Another option, is to 'map' the object property structure a bit more:

"mock" : { "faker": {"company" : {"companyName": {"min-words": 3, "max-words": 6}}}}

More typing, twice the amount of brackets/nesting we need but more closely resembles the actual object structure (so in this case, we might take faker/chance/any-other-lib). One might remove the "mock" even but I like it because mostly, it is unambiguous and can be easily be spotted by people less familiar with JSON Schema (and what belongs there, what doesn't).

I've been hacking in Clojure the past few years btw, and recently active with Node again but I use wisp since my brain really loves polish notation so much better now... reading JS is hard, writing it (good) is a pain which is and why (time constraints as well) I haven't come up with a working prototype yet - I also realized format.js has faker baked in hard and one might not want to break existing functionality (functions expecting (faker, schema) to be passed. Another option would be (perhaps also why mock as a schema key is convenient) to have a second one on the side for backwards compatibility.

Add support to different status code rather than 200

Relax response's media type

Currently mocks are only generated for responses of the media type application/json (https://github.com/RePoChO/raml-mocker/blob/master/src/index.js#L156).

Any (custom) JSON media type should be allowed though. As a solution, one may either:

• Mock the first media type matching /application\/[A-Za-z.-0-1]*\+?json/ in the media type map of the response's body property
• Mock all media types matching /application\/[A-Za-z.-0-1]*\+?json/ in the media type map of the response's body property
  • Would require mock() and example() to return either
    • a map of media types
    • default to i.e. application/json or the first media type in the list and providing mockByMediaType() / exampleByMediaType() methods; analogous to mockByCode()

Any inputs? Would be happy to draft a PR :)

Option path to support array type

Hi @dmitrisweb

Can we possibly have the Raml folder path (options.path) to support an array type (array of directiory paths) as well as the original string type.

Regards

Use a test framework to improve the testing and the test results.

In order to obtain a reliable tests results It would be better to use a testing framework like Mocha to perform some tests and get better results.

If the code coverage is also calculated should be even better.

PATCH not supported

I've been struggling a little bit with this until I've decided to surf into your code. Currently if you have a resource defined in RAML that supports update through PATCH, that doesn't get mocked.
In the index.js, line 123 there's a regular expression filtering it:

        if (method.method && /get|post|put|delete/i.test(method.method) && method.responses) {

With a little amendment it works fine

        if (method.method && /get|post|put|patch|delete/i.test(method.method) && method.responses) {

I'm kind of on a rush, as soon as I get a few minutes free I'll fork, fix and create Pull Request, but any case you have this reported.

The format should be defined in lowercase and doesn't allow camelCase.

The schema format property should allow camelCase and be smarter.

RAML 1.0 support

Please support RAML 1.0. This would be awesome.

Circular $ref dependencies are not allowed

With a schema like this one:

{
    "$schema": "http://json-schema.org/schema",
    "definitions": {
        "node": {
            "type": "object",
            "properties": {
                "id": {
                    "type": "string",
                    "format": "id"
                },
                "label": {
                    "type": "string"
                },
                "children": {
                    "type": "array",
                    "items": {
                        "$ref": "#/definitions/node"
                    }
                }
            },
            "required": ["id", "label", "children"]
        }
    },
    "items": {
        "$ref": "#/definitions/node"
    },
    "type": "array"
}

raml-parser throws an exception using {dereferenceSchemas: true}:
Error parsing: TypeError: Converting circular structure to JSON

This is due to the circular definition of the schema.

With the old system this was allowed as the $ref was resolved at runtime and in this example the array length could be 0.

Reference: #2

The schema parser should be able to import external schema files

The schema parser should be able to import external schema files.

The problem of this issue is knowing the path of the parsed raml file. The parser plugin should provide the path of the raml or the path of the schema file.

The easiest part of this issue is to load external schemas with uri like:
http://mydomain.com/subSchema