<commit_before># Mockercinno

Simple, declarative mock server.

[![Build Status](https://travis-ci.org/alexnaish/mockercinno.svg?branch=master)](https://travis-ci.org/alexnaish/mockercinno)
[![Code Climate](https://codeclimate.com/github/alexnaish/mockercinno/badges/gpa.svg)](https://codeclimate.com/github/alexnaish/mockercinno)
[![Dependencies](https://david-dm.org/alexnaish/mockercinno.svg)](https://david-dm.org/alexnaish/mockercinno)
[![Latest Release](https://img.shields.io/npm/v/mockercinno.svg)](https://www.npmjs.com/package/mockercinno)


## Introduction

Made to allow easy but flexible mocking out of external systems. Write your service stubs as JSON (or in JS files that export JSON) in your project, point `mockercinno` to them and let the magic happen. Features live-reloading of mock files to allow a quicker and easier development process.

## Installation

`npm install mockercinno --save-dev`

## Usage

`./node_modules/bin/mockercinno --pattern 'path/to/mocks/**/*'`

### CLI Options


* `--file` / `-f`
	* Used to specify a single file by taking an exact file location. No live-reloading.
* `--pattern` / `-p`
	*  Takes a glob pattern in order to specify multiple files over multiple directories. Files and directories matching the glob are watched and will trigger live-reloading of the mock server.
* `--port`
	* Takes a numerical value to specify the port for `mockercinno`.
* `--strict`
	* Specifies whether to throw an error if an imported mock file is invalid.

## Prerequisites

*  Node 8 (or greater)

## Example Mock File

```

[
	{
		"name": "Example Mock",
		"request": {
			"method": "GET",
			"path": "/standard/*"
		},
		"response": {
			"status": 200,
			"body": {
				"data": "something"
			}
		}
	}
]

```

## Advanced Details

### Route Matching

The way mocks are matched against incoming requests follows a similar pattern to how Express handles route definitions.
If you specify a "greedy" route first, it will catch all similar routes even if the others are more specific.

### Request Schema

There are several levels of granularity when specifying a request depending on your requirements. The properties specified are the minimum requirements for the request to match your mock.
Properties are optimistically matched, meaning that if you specify one particular query parameter and the request contains that parameter in addition to others, it will return the mock as a match.
You can limit a mock against the following properties of a request:

*  `method` - An uppercased string of the required HTTP request method.
*  `path` - A string indicating required request path.
    *  Direct - `/some/path/here`
    *  Named - `/some/:name/here`
    *  Greedy - `/some/route/*`
*  `query` - An object containing required key-value query parameters.
*  `headers` - An object containing key-value header parameters. **All keys must be lower-cased**
*  `body` - An object for which a request body must contain for it to match.
*  `custom` - An object which allows a custom function to be run against the mock.

`query`, `header` and `body` parameters can be tested in the following ways:
		* String (simple exact string matching)
		* RegExp (see how to define below)

An example of the above settings:

```

[
	{
		"name": "Specific Request Example",
		"request": {
			"method": "POST",
			"path": "/standard/*",
			"query": {
				"test": "yes",
				"email": {
					type: "regex",
					value: ".*?@example\.com",
					modifiers: "i"
				}
			},
			"headers": {
				"x-test": "yes",
			},
			"body": {
				"user": "example",
				"email": {
					type: "regex",
					value: ".*?@domain\.com",
					modifiers: "i"
				}
			},
			"custom": {
				// Location of the function
				location: "custom/matchers/file",
				// Additional arguments that will be spread onto the function
				additionalArgs: ["something", "for", "this", "mock"]
			}
		},
		"response": {
			"status": 200,
			"body": {
				"data": "something"
			}
		}
	}
]<commit_msg>Fix custom function example in readme<commit_after># Mockercinno

Simple, declarative mock server.

[![Build Status](https://travis-ci.org/alexnaish/mockercinno.svg?branch=master)](https://travis-ci.org/alexnaish/mockercinno)
[![Code Climate](https://codeclimate.com/github/alexnaish/mockercinno/badges/gpa.svg)](https://codeclimate.com/github/alexnaish/mockercinno)
[![Dependencies](https://david-dm.org/alexnaish/mockercinno.svg)](https://david-dm.org/alexnaish/mockercinno)
[![Latest Release](https://img.shields.io/npm/v/mockercinno.svg)](https://www.npmjs.com/package/mockercinno)


## Introduction

Made to allow easy but flexible mocking out of external systems. Write your service stubs as JSON (or in JS files that export JSON) in your project, point `mockercinno` to them and let the magic happen. Features live-reloading of mock files to allow a quicker and easier development process.

## Installation

`npm install mockercinno --save-dev`

## Usage

`./node_modules/bin/mockercinno --pattern 'path/to/mocks/**/*'`

### CLI Options


* `--file` / `-f`
	* Used to specify a single file by taking an exact file location. No live-reloading.
* `--pattern` / `-p`
	*  Takes a glob pattern in order to specify multiple files over multiple directories. Files and directories matching the glob are watched and will trigger live-reloading of the mock server.
* `--port`
	* Takes a numerical value to specify the port for `mockercinno`.
* `--strict`
	* Specifies whether to throw an error if an imported mock file is invalid.

## Prerequisites

*  Node 8 (or greater)

## Example Mock File

```

[
	{
		"name": "Example Mock",
		"request": {
			"method": "GET",
			"path": "/standard/*"
		},
		"response": {
			"status": 200,
			"body": {
				"data": "something"
			}
		}
	}
]

```

## Advanced Details

### Route Matching

The way mocks are matched against incoming requests follows a similar pattern to how Express handles route definitions.
If you specify a "greedy" route first, it will catch all similar routes even if the others are more specific.

### Request Schema

There are several levels of granularity when specifying a request depending on your requirements. The properties specified are the minimum requirements for the request to match your mock.
Properties are optimistically matched, meaning that if you specify one particular query parameter and the request contains that parameter in addition to others, it will return the mock as a match.
You can limit a mock against the following properties of a request:

*  `method` - An uppercased string of the required HTTP request method.
*  `path` - A string indicating required request path.
    *  Direct - `/some/path/here`
    *  Named - `/some/:name/here`
    *  Greedy - `/some/route/*`
*  `query` - An object containing required key-value query parameters.
*  `headers` - An object containing key-value header parameters. **All keys must be lower-cased**
*  `body` - An object for which a request body must contain for it to match.
*  `custom` - An object which allows a custom function to be run against the mock.

`query`, `header` and `body` parameters can be tested in the following ways:
		* String (simple exact string matching)
		* RegExp (see how to define below)

An example of the above settings:

```

[
	{
		"name": "Specific Request Example",
		"request": {
			"method": "POST",
			"path": "/standard/*",
			"query": {
				"test": "yes",
				"email": {
					type: "regex",
					value: ".*?<EMAIL>",
					modifiers: "i"
				}
			},
			"headers": {
				"x-test": "yes",
			},
			"body": {
				"user": "example",
				"email": {
					type: "regex",
					value: ".*?<EMAIL>",
					modifiers: "i"
				}
			},
			"custom": {
				// Location of the function
				function: "custom/matchers/file",
				// Additional arguments that will be spread onto the function
				additionalArgs: ["something", "for", "this", "mock"]
			}
		},
		"response": {
			"status": 200,
			"body": {
				"data": "something"
			}
		}
	}
]
{'fraction_non_alphanumeric': 0.12727500941383205, 'fraction_numerical': 0.0017572486506840718, 'mean_word_length': 3.5272727272727273, 'pattern_counts': {'":': 50, '<': 5, '<?xml version=': 0, '>': 5, 'https://': 16, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2385120', 'n_tokens_mistral': 2712, 'n_tokens_neox': 2405, 'n_words': 889}