We should require certain fields like path within the match objects, or at least default to something like /.

For now it is not possible to write such code in tests:

srv.delete('/rules', {status: 204});
srv.post('/rules', {status: 201});

because attaching to same path for the second time will unregister all routes with same path, ignoring method

We should figure out how to add HTTPS support to http://mockyeah.js.org/. I've done so with Cloudflare CDN and GitHub Pages before.

Relates to #81.

When we're defining mocks in the proxy use case (e.g., #106), it would feel more natural to use url rather than path, so we should support an alias key.

Instead of:

mockyeah.get({
  path: 'http://localhost:8888/foo?ok=yes'
}, { text: 'bar' })

It'd be nice to say:

mockyeah.get({
  url: 'http://localhost:8888/foo?ok=yes'
}, { text: 'bar' })

Since header names are case-insensitive, we should do a case-insensitive match.

When using mockyeah directly in tests the test runner stdout will always contain the log messages, e.g.

Scenario: Make something after logging in
[mockyeah][REQUEST][GET] /wp-json/wp/v2/something (1ms)
[mockyeah][REQUEST][POST] /api/users/401/session (1ms)
      ✓ Given: I logged in (384ms)

While this is very helpful during test development, for test reporting it introduces noise and makes the test results hard to read.

We'd like to write test code like

var mockyeah = require('mockyeah');
mockyeah.log = false;
mockyeah.get(/wp-json\/wp\/v2\/something/, { json: '{ "info":"something"}'});

and in case we have problems while implementing a test we simply change to mockyeah.log = true;

It's not clear to me what the differences between these options are. We should consider refactoring or at least documenting better.

For marketing purposes, a Twitter account could be good to grab. Too bad looks like https://twitter.com/mockyeah is already taken.

So that it feels more natural to mock some requests when using the proxy...

Instead of:

mockyeah.get('/http://localhost:8888/foo?ok=yes', { text: 'bar' })

It'd be nice just only have to do:

mockyeah.get('http://localhost:8888/foo?ok=yes', { text: 'bar' })

with no leading slash.

Sometimes it's useful to start with a base fixture file but transform it slightly to be relevant to the current test. Rather than requiring us to manually read & parse the file then use json, why not offer a fixture transform function option to be used optionally alongside existing fixture option?

Relates to #403.

The tests are no longer running on TravisCI since we moved to the mockyeah organization.

The Expectation API link doesn't navigate to it's respective page and it's first child .expect() anchors part way down the page. As a result, there is not navigation linking to the top of the page.

Snapshot recording could be noisy and result in lots of fixtures that the user doesn't want or need. We could support starting a snapshot recording session that is scoped to only some URLs, e.g., by accepting a string the URL should contain, a glob pattern, or regular expression. This could be part of the CLI as well.

The repo wiki is not conducive to collaboration. Thoughts on moving the documentation to a github pages site?

Support starting server in HTTPS mode, to avoid CORS issues from HTTPS browser applications.

Why are more people not finding mockyeah? Are there keywords that should be added? How do the keywords for related projects compare?

Mock expectation support was added with https://github.com/ryanricard/mockyeah/blob/master/CHANGELOG.md#0151---2016-11-02 as an undocumented feature. The api needs to be finalized and documentation added.

Add a feature to force an exact match instead of default partial matching on query parameters, request body, HTTP headers, and/or cookies, so that a mock won't match if it includes any unspecified additional or extraneous values. There may also be an integration with the expectation features here too.

Something like:

mockyeah.get({ params: { only: '1' }, exact: true })

Which I think should default to just params and body exact matches, not headers or cookies.

Then we can specifically target headers, cookies, etc., with:

mockyeah.get({
  params: { only: '1' },
  body: { only: '1' },
  headers: { only: '1' },
  cookies: { only: '1' },
  exact: {
    params: true,
    body: true,
    headers: true,
    cookies: true
  }
})

We may want to exempt the Cookie header from the headers exact matching, perhaps only when cookies is also present.

Project is currently bound to ESLint ^1.10.3, latest is 3.9.1. There are breaking changes between versions, so updating will be more involved than binding latest in package.json.

We should note that mock-yeah npm package is no longer used, in favor of mockyeah.

We should move the *.js, server, app, and lib directories under a new src subdirectory, if not also test and tasks. This will enable and simplify tooling configuration like ESLint, Babel (#92), etc.

It's just a suggestions to add features to this great library.

In hermetic ui testing (as defined by google) we mock out backend, considering the front end a system by itself. System level testing would then correspond to e.g. clicking, responding with mockyeah, but also verifying the sent request as is possible for example in wiremock.

Feature: request verification
As a front developer I want to verify the requests sent by my application in order to have system test coverage
Scenario: my application composes a complex request
Given I automate my UI test with selenium
And I choose various options at the UI for a complex request
And I mock out back end with mockyeah (from my selenium / protractor code)
When I confirm my changes
Then I can obtain the sent request from mockyeah
And verify the request is as I expect

Typically, it's important to

• configure if request journal is active or not in order to avoid memory problems in soak testing
• reset the request journal to only check over requests of a certain test run

Easier to configure rather than call mockyeah.proxy() manually/programmatically.

By test example
mockyeah.get('/wondrous', { status: 422 }); will return a response with code 422.
However, when I set
mockyeah.get('/wondrous', { status: 422, message: "MYERRORCODE" }); mockyeah won't start.
Error message:
Error: Response option(s) invalid. Options must include one of the following: fixture, filePath, html, json, text, status, headers, raw, latency, type
at validateResponse (/home/sebastian/legolas/frontend/node_modules/mockyeah/app/lib/RouteResolver.js:42:11)

Our backend will return 422 but with several error codes in the field message. Therefore for us at least, it is necessary to be able to define this field

mockyeah-cli's documentation is very terse, which might be ok; nevertheless, we should brainstorm improvements that may be helpful to new users.

• Document new param matching functionality
• Document proxy middleware behavior
• Consider creating Gitbook documentation site to house v1 and pre v1 documentation

Since we use query in matches (due to Express path segments called parameters), we should support the same language with the expect API.

We currently support JSON-parsed body matches for mocks. We should also support raw string body matching and regular expressions against those.

@therynamo, are you interested in writing a test to assert the availability of the middleware method you exposed? I am doing some heavy refactoring and I want to ensure I don't break your implementation.

1.) I have a default test setup with .get(/someRoute/, {json:someResponse1})
2.) alternative test starts
3.) alternative test sets .get(/someRoute/, {json:someResponse2})
4.) test requests /someRoute/
==> mockyeah returns someResponse1
Expected => mockyeah returns someResponse2

Note:
I don't want to run a mockyeah.reset as I have a full workflow I want to test

When a response option is not specified, mockyeah responds with no content. This has lead to some confusion for response options that are specified incorrectly (e.g. wrong property name, misspelled, etc.).

It would be nice if our configuration supported more filenames and formats, including .json, .js, .yaml, .*rc, and embedded in package.json. Perhaps use https://github.com/davidtheclark/cosmiconfig.

Relates to #35.

mockyeah's use of latest ECMAScript features make incompatible with older versions of node. We should consider increasing its compatibility so more people can benefit from its use.

Done when:

• A minimum Node version is determined.
• CI automation is implemented to assert compatibility with multiple Node versions (e.g. https://github.com/victorbjelkholm/autochecker)
• mockyeah is updated to support the lowest agreed upon version of Node.

mockyeah's documentation should be clear and succinct. It needs to be easy enough to consume that new users can easily understand its use-case, while including the details needed to understands its complete api.

Gulp is not needed to execute linting and testing tasks. Linting and testing framework binaries can be executed from development dependencies via NPM Scripts.

Review how mockyeah finds its dot file (i.e. .mockyeah). Projects can have multiple dot files (e.g. one in project root for development and one in test directory for test configuration), ensure mockyeah is finding the correct file depending on main module directory context.