Fixtures

What are fixtures?

Think API intercept and modify behavior in testing libraries

Stoobly fixtures are predefined responses used during mocking. Fixtures are used in the case where a recorded response is not found for the current request.

Why use fixtures?

• Quick way to mock a request in the case where a specific response is difficult to record

• Serve assets that otherwise should not be recorded

Example Fixtures YAML File

The following is an example file for a fixtures-response.yml passed to the --fixtures-response-path option:

DELETE:
    /users/d+?:
        headers: {}
        path: ./relative-path-to-response
        status_code: 200
GET:
    /users/d+?:
        headers: {}
        path: ./relative-path-to-response
        status_code: 200
POST:
    /users:
        headers: {}
        path: ./relative-path-to-response
        status_code: 200
PUT:
    /users/d+?:
        headers: {}
        path: ./relative-path-to-response
        status_code: 200  

Public Directory

A specified public directory can serve as a folder where files in the folder with relative paths that match a request's path are served. For example, given the request path:

/users/1 with header Content-Type: application/json , and given

<PUBLIC-DIRECTORY-PATH> is the path the public directory then:

• File <PUBLIC-DIRECTORY-PATH>/users/1.json will be searched first

• If not found, then <PUBLIC-DIRECTORY-PATH/users/1 will be searched

Defaults

Unless otherwise specified:

• status_code defaults to 200

• Response header Content-Type will be inferred from the fixture file extension

Next Steps

How to Use Fixtures