blad / mockingjays Goto Github PK

Add support for caching binary files such as images.

The current implementation naively identifies textual response types and pipes non-textual responses to the output buffer.

In some instances we may want to copy the fixtures from the base cache directory to the override directory. A flag would be useful, so as fixtures get used from the base, they are copied to the override directory.

new Mockingjays().start({
  copyToOverrideDir: (request) -> request.host.indexOf('auth') < 0 // only copy fixtures not part of the auth host.
});

new Mockingjays().start({
  copyToOverrideDir: true // Copy all fixtures to override directory.
});

Add support for before and after hooks, to modify the request or response objects.

new Mockingjays().start({
  // ...  usual options
  before: request => {
    {body, qa, host, path, headers} = request
    // .. modify request before it is processed by Mockingjays
    return {body, qa, host, path, headers}
  },


  after: response => {
    // modify response object.
    response.code = 200
    response.data = {...}
    return response
  }
});

--version option should return the version of the library being used.

--help should return a list of available options and descriptions for those options.

Playback functionality would would allow the user to:

• Verify How a Request's Response has Changed
• Provide a Mechanism for Integration Testing the Source API
• Ability to Refresh the Cached Responses

mockingjay playback \
--verbose \ # Determine verbosity of output
--no-refresh # Determine if the Cache Should be updated based on the server response

Allow users to bypass the application whitelist of headers during hash and caching phase.

mockingjays \
--cacheDir=./fixtures \
--baseServerUrl=http://swapi.co \
--trackRequestHeaders \  # Cache and Consider all Request Headers
--trackResponseHeaders # Cache all Response Headers
--trackAllHeaders # Tracks all Request and Response Headers [Used in place of both of the above options]

Add Support for WebSocket interactions...

A WebSocket observer could

• Learn the sequence of messages to expect and reproduce the response.
• Reproduce a previously observed sequence of emitted messages.

Given the target server is not available, or still in development, but the expected response is known, then allow the user to specify the response headers, and payload for a request.

Not all requests are stateless, most request will capture the application state at some point in time.

For example an application to manage user may have an endpoint for getting a list of users and an endpoint for creating a new user in the system. A request fulfilled any point will reflect the users up to that point in time. A request to create a new user in a real system will affect the output of the request that retrieves this list of users.

We aim to try and capture this transition. In order to do so, we need to define which endpoints are affected by thses statefull operations. Since two stateless requests for a list of users might be indistinguishable from one another, we must add a internal uniqueness identifier to ensure we can distinguish between a request pre and post the stateful operation.

Having a file where the stateful operation and it's affected endpoints will be required for defining when a transition should occur.

{
  "/createUser": {
    "method": "POST",
    "status": 200,
    "links": [
      {
        "path": "/getUsers",
        "method": "GET"
      }
    ]
  }
}

The createUser is the stateful operations which will trigger a transition and affect the output for future getUsers requests.

Within the Proxy server, all requests will need to contain a key that indicates which transition they are part of. An empty transaction key, will mean that they are part of the initial state, so when no transitions have occurred, then the cache hashing should arrive at the initial state.

When a stateful operation occurs, the proxy will automatically add the transaction key to request for the linked requests to ensure uniqueness and capture the new state of the operation.

The Cache File Will have the follow format:

{
  "request": {
    "hostname": "swapi.co",
    "port": 80,
    "path": "/api/",
    "method": "GET",
    "headers": {},
    "body": "",
    "transaction": "268db6a84031ba33a345f573e79e8bc7c94ca26d"
  }

Where the transaction key is the hash of the request that created the new state.

Add Newline to End of Cache Files.

Strip/Encode the following from directory names:

< (less than)
> (greater than)
: (colon)
" (double quote)
/ (forward slash)
\ (backslash)
| (vertical bar or pipe)
? (question mark)
* (asterisk)

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

As a user it would be ideal, if there was a way to determine a which fixtures were not being accessed any longer in a session, or set of sessions or time period.

Allow the user to specify which content types to avoid caching...

mockingjays \
  --port=9000 \
  --cacheDir=/var/app/fixtures \
  --serverBaseUrl=http://swapi.co
  --ignoreContentType='image/*,text/html' # Content Types to Not Cache

As a user I want to be able to rehash the requests when the source url is changed or I want to consider or ignore a header of the request.

Modifying the options object in place leads to undesired behavior when using the JS API.

Reduce the amount of standard output to just:

Request Recieved: /api/people/1/ GET Learning

and

Request Recieved: /api/people/1/ GET Repeating

Set the --verbose output to something like:

Request Recieved: /api/people/2/ GET
Learning::  {"url":"http://swapi.co/api/people/2/","body":"","headers":{},"method":"GET"}
Successfully Created Directory: /var/fixtures/api/people/2

Responding:  200 application/json

content-type: application/json
cookie: user=123;name=helloworld
date: 2015-12-13 12:00:00

{"name":"C-3PO","height":"167","mass":"75","hair_color":"n/a","skin_color":"gold","eye_color":"yellow","birth_year":"112BBY","gender":"n/a","homeworld":"http://swapi.co/api/planets/1/","films":["http://swapi.co/api/films/5/","http://swapi.co/api/films/4/","http://swapi.co/api/films/6/","http://swapi.co/api/films/3/","http://swapi.co/api/films/2/","http://swapi.co/api/films/1/"],"species":["http://swapi.co/api/species/2/"],"vehicles":[],"starships":[],"created":"2014-12-10T15:10:51.357000Z","edited":"2014-12-20T21:17:50.309000Z","url":"http://swapi.co/api/people/2/"}