Scott Chamberlain

R package test suites that include HTTP requests are dependent on an
internet connection being up, the internet connection speed, changing
behavior of the remote server, as well as changing response formats/data
from a remote server. We ideally want to test functionality of our
package relative to some known data that isn't intermittently
unavailable or changing. Caveat is that we do want to make sure the
package fails well, including fails well in response to server failures,
but these responses can be cached.

One way to deal with the problems above is to store responses from HTTP
requests and use them in subsequent requests so that test suites are
using a predictable set of data on each run of the test suite. We don't
have to reinvent the wheel to look for a solution, and the solution has
been around for a while. The programming language
[Ruby](https://www.ruby-lang.org/en/) has had
[vcr](https://github.com/vcr/vcr) since
[2010](https://rubygems.org/gems/vcr/versions) (and ported to 15 other
languages).

Ruby's [vcr](https://github.com/vcr/vcr) plugs in to many other HTTP
gems via [webmock](https://github.com/bblimke/webmock), another Ruby
gem. `webmock` does the actual matching of HTTP requests (but does not
store any response), while `vcr` leverages `webmock` but then stores the
HTTP response.

About 3.5 years ago I made my first commits on ports of Ruby's vcr to R
called [vcr](https://github.com/ropensci/vcr/commit/6690a23), and one
for Ruby's webmock, called
[webmockr](https://github.com/ropensci/webmockr/commit/7fe4225). It took
me a long time to get these out on CRAN, which I'll talk about below.

Let's get right into it. How do we use `vcr`?

## Setup

The setup within your package goes like so. In the `tests/` folder,
you'll end up with a new folder called `fixtures`. You can control what
this is called by configuring vcr via `vcr::vcr_configuration()`. Let's
assume we're working with a package called `foo`.

::: {.highlight}
``` {.chroma tabindex="0"}
foo/tests├── fixtures/vcr_cassettes├── test-all.R└── testthat
```
:::

Inside of `testthat/` we need to insert some configuration for `vcr`,
which can go in a helper file like so:

::: {.highlight}
``` {.chroma tabindex="0"}
foo/tests/testthat├── helper-foo.R
```
:::

Within the `helper-foo.R` file we need something like so to tell `vcr`
where to store cached HTTP responses:

::: {.highlight}
``` {.chroma tabindex="0"}
library("vcr")vcr_configure(dir = "../fixtures/vcr_cassettes")
```
:::

`vcr` will set up the new folders given in the `dir` parameter of
`vcr_configure` if they don't already exist.

You may have figured this out already, but to be sure: "cassette" means
essentially a thing to which you are recording HTTP interactions.
There's other terminology in `vcr` like "record" and "eject". See the
[terminology book
section](https://books.ropensci.org/http-testing//intro.html#terminology)
for more.

## Basic usage

Load [vcr](https://github.com/ropensci/vcr),
[crul](https://github.com/ropensci/crul), and `testthat`

::: {.highlight}
``` {.chroma tabindex="0"}
library(vcr)library(crul)library(testthat)
```
:::

Make a `crul` connection client.

::: {.highlight}
``` {.chroma tabindex="0"}
cli <- crul::HttpClient$new(url = "https://api.crossref.org")
```
:::

Then wrap the actual HTTP request call in a call to
`vcr::use_cassette()`.

::: {.highlight}
``` {.chroma tabindex="0"}
use_cassette(name = "helloworld", {  res <- cli$get("works", query = list(rows = 3))  expect_is(res, "HttpResponse")})#> CrulAdapter enabled!#> net connect allowed#> net connect disabled#> ejecting cassette: helloworld#> CrulAdapter disabled!
```
:::

The first time the above code block is run real HTTP connections are
allowed because it doesn't match any previous requests, and the response
is cached. The second time the request is made, the cached response is
used.

The cached response is a YAML file - an example is show below. The
advantage of the format is that it's machine readable but humans can
also read them so you can inspect your cached HTTP responses to better
be able to construct/debug your test suite.

``` {tabindex="0"}
http_interactions:- request:    method: get    uri: https://api.crossref.org/works?rows=3    body:      encoding: ''      string: ''    headers:      User-Agent: libcurl/7.54.0 r-curl/3.2 crul/0.5.2      Accept-Encoding: gzip, deflate      Accept: application/json, text/xml, application/xml, */*  response:    status:      status_code: '200'      message: OK      explanation: Request fulfilled, document follows    headers:      status: HTTP/1.1 200 OK      content-type: application/json;charset=UTF-8      vary: Accept      access-control-allow-origin: '*'      access-control-allow-headers: X-Requested-With      content-length: '5360'      server: http-kit      date: Sat, 28 Apr 2018 15:12:29 GMT      x-rate-limit-limit: '50'      x-rate-limit-interval: 1s      connection: close    body:      encoding: UTF-8      string: '{"status":"ok","message-type":"work-list","message-version":"1.0.0","message":{"facets":{}},"items-per-page":3,"query":{"start-index":0,"search-terms":null}}'  recorded_at: 2018-04-28 15:12:29 GMT  recorded_with: vcr/0.1.0, webmockr/0.2.6, crul/0.5.2
```

## Why vcr and webmockr?

The power of both vcr and webmockr is they abstract away the gory
details, and present a single user interface to (eventually) many
different HTTP R libraries (only `crul` right now, but `curl` and `httr`
are in development). In addition, though not available yet, vcr will
have many different serialization formats; it has only YAML now, but
could include JSON and other formats. Both packages will handle a
relatively complex set of use cases that come from many years of input
from lots of users.

## http testing book

To integrate documentation for `vcr` and `webmockr` and related tools
we've started a new [bookdown](https://bookdown.org/home/) called the
[HTTP Testing Book](https://books.ropensci.org/http-testing//).

The book will cover high level concepts of testing R packges that make
HTTP requests, how to approach the general problem, how to use webmockr
by itself, and how to use vcr. As we add more integrations with http R
packages we'll add more content/chapters to document the new stuff.

Do let us know if you have any feedback on the book! You can send a PR
if you want to suggest a change by clicking on the edit button.

## vcr in the wild

R's `webmockr` and `vcr` are on CRAN. In addition, there are two
packages on CRAN using `vcr` for test caching. They are:

- [ritis](https://cran.rstudio.com/web/packages/ritis/)
- [worrms](https://cran.rstudio.com/web/packages/worrms/)

There are a number more on GitHub, soon to head to CRAN:

- [rredlist](https://github.com/ropensci/rredlist/tree/vcr-integration)
- [bold](https://github.com/ropensci/bold/tree/with-vcr)
- [wikitaxa](https://github.com/ropensci/wikitaxa/tree/with-vcr)
- [microdemic](https://github.com/ropensci/microdemic/)
- [zbank](https://github.com/ropenscilabs/zbank)
- [rplos](https://github.com/ropensci/rplos)

You can get a sense for how `vcr` is used in real packages by looking at
the `tests` directory in any of the packages above.

## Security

Testing HTTP packages often involves using authentication to the web
service. In addition, responses may contain sensitive data pertaining to
users or other such things. If you push your stored HTTP responses onto
the public web you most definitely DO NOT want your secure tokens/etc.
to be included.

We have a way to deal with this already, where you can replace strings
matching a pattern with a placeholder. The HTTP responses stored on disk
will have the placeholder only. For example:

::: {.highlight}
``` {.chroma tabindex="0"}
vcr_configure(  filter_sensitive_data = list("<<<my_api_key>>>" = Sys.getenv('API_KEY')))
```
:::

Here, we're replacing any instance that matches the output of
`Sys.getenv('API_KEY')` (let's say its `123abc`), with
`"<<<my_api_key>>>"`. When you run tests, vcr swaps `"<<<my_api_key>>>"`
for your actual API key of `123abc` so your tests run smoothly.

See the [Security
chapter](https://books.ropensci.org/http-testing//security) in the HTTP
Testing Book for more. Feedback on security in vcr much appreciated!

## Logging

You can use logging in `vcr` to set an IO-like object that vcr will log
output to. This is a useful way to troubleshoot what vcr is doing.
Beware that logging isn't completely built out yet.

To set up logging, set `log` and `log_opts` options in your
`vcr_configure()` call:

::: {.highlight}
``` {.chroma tabindex="0"}
vcr_configure(  log = TRUE,   log_opts = list(file = "vcr.log", log_prefix = "Cassette", date = TRUE))
```
:::

Here, we set `log = TRUE`, then set a file to log to, a log prefix (so
each line has prefix `[Cassette: <your cassette>]`), and use date (if
`FALSE`, date not included in each log line).

See the [Logging
chapter](https://books.ropensci.org/http-testing//logging) in the HTTP
Testing Book for more.

## Porting from other languages

I sometimes peruse [Rubygems](https://rubygems.org/) and
[pypi](https://pypi.org/) looking for ideas in topic areas that I
develop packages in. I noticed `vcr` and `webmockr` at some point in
Ruby land, and over 3 years ago started in earnest porting them over to
R.

The process has taken much much longer than I had hoped, and let's just
say I have notes. Attempting to port a library from one language to
another in its entirety is tough.

I do understand Ruby relatively well, but still I ran into a fair bit of
code I had never seen before. This often meant running Ruby code from
vcr/webmock and figuring out what they expect as output of a method
call, then thinking about how to port that to R.

Probably the biggest stumbling block was [monkey
patching](https://en.wikipedia.org/wiki/Monkey_patch). Ruby's webmock
works by replacing methods from various Ruby HTTP gems with their own to
change their behavior when run. R doesn't seem to allow monkey patching.
After fooling around trying the monkey patching approach, I gave that up
and figured that I needed to make changes in the R HTTP libraries
themselves to hook into webmockr (side note: since starting webmockr,
now httr has added a callback mechanism, which I think I'll be able to
leverage so no further changes will be needed in httr). Changing HTTP
libraries was no problem in my own HTTP library
[crul](https://github.com/ropensci/crul), but not so easy in ones I
don't maintain.

Last, if I could start over, I'd probably try to get to a MVP much
faster, then add more features, instead of trying to port everything
over before anything was put out.

## Upcoming work

There's still a lot of work to do on vcr ant its companion webmockr.
Please do get in touch with any feedback. Let us know if you have any
problems using vcr in your package. Here's some highlights of upcoming
work:

- You can use `vcr::insert_cassette` alone, and then
  `vcr::eject_cassette` when you're done, but that behavior isn't quite
  working yet. [(#24)](https://github.com/ropensci/vcr/issues/24)
- We will support more matchers in the future, including matching by URI
  path (`foo` in `https://bar.com/foo`), host (e.g. `bar.com` in
  `https://bar.com/foo`), and request body
  [(#70)](https://github.com/ropensci/vcr/issues/70)
- There's many features that Ruby vcr has that we don't have yet, too
  many to list here :)
- Performance work: e.g., loading time of cached HTTP responses can be
  slow, see [(#66)](https://github.com/ropensci/vcr/issues/66)
- Work on integrating `curl` lib going on in `webmockr` in a branch
  [adapter-curl](https://github.com/ropensci/webmockr/tree/adapter-curl)
- Work on integrating `httr` lib going on in `webmockr` in a branch
  [adapter-httr](https://github.com/ropensci/webmockr/tree/adapter-httr)


R package test suites that include HTTP requests are dependent on an internet connection being up, the internet connection speed, changing behavior of the remote server, as well as changing response formats/data from a remote server. We ideally want to test functionality of our package relative to some known data that isn’t intermittently unavailable or changing.

vcr: record and replay HTTP requests

## webmockr

`webmockr` is an R library for stubbing and setting expectations on HTTP
requests.It is a port of the Ruby gem
[webmock](https://github.com/bblimke/webmock).

`webmockr` works by plugging in to another R package that does HTTP
requests. It currently only works with
[crul](https://github.com/ropensci/crul) right now, but we plan to add
support for [curl](https://github.com/jeroen/curl) and
[httr](https://github.com/r-lib/httr) later.

`webmockr` has the following high level features:

- Stubbing HTTP requests at low http client level
- Setting expectations on HTTP requests
- Matching requests based any combination of HTTP method (e.g.,
  GET/POST/PUT), URI (i.e., URL), request headers and body
- Will soon integrate with [vcr](https://github.com/ropensci/vcr) so
  that you can cache real HTTP responses - and easily integrate with
  `testthat`

`webmockr` has been on CRAN for a little while now, but I've recently
made some improvements and am nearing anotherCRAN release, which is also
preparation for a first release of the related
[vcr](https://github.com/ropensci/vcr) package. The following is arun
down of major features and how to use the package, including a bit on
testing at the end.

## Similar art in other languages

`webmockr` was most closely inspired by Ruby's
[webmock](https://github.com/bblimke/webmock), but there are others out
there, e.g,. [HTTPretty](https://github.com/gabrielfalcao/HTTPretty) and
[pook](https://github.com/h2non/pook) for Python, from which we'll steal
ideas as time allows.

## Installation

`webmockr` is on CRAN, so you can install that version

::: {.highlight}
``` {.chroma tabindex="0"}
install.packages("webmockr")
```
:::

But I've been making some improvements, so you'll probably want the dev
version:

Install some dependencies

::: {.highlight}
``` {.chroma tabindex="0"}
if (!requireNamespace("remotes", quietly=TRUE)) install.packages("remotes")remotes::install_github(c("ropensci/vcr@webmockit", "ropenscilabs/fauxpas"))
```
:::

Install `webmockr`

::: {.highlight}
``` {.chroma tabindex="0"}
remotes::install_github("ropensci/webmockr")
```
:::

Load `webmockr`

::: {.highlight}
``` {.chroma tabindex="0"}
library(webmockr)
```
:::

## Using webmockr

After loading `webmockr`

::: {.highlight}
``` {.chroma tabindex="0"}
library(webmockr)
```
:::

`webmockr` is loaded but not "turned on". At this point `webmockr`
doesn'tchange anything about your HTTP requests.

Once you turn on `webmockr`:

::: {.highlight}
``` {.chroma tabindex="0"}
webmockr::enable()
```
:::

`webmockr` will now by default **NOT** allow real HTTP requests from the
httplibraries that adapters are loaded for (right now only `crul`).

Next, you'll want to think about stubbing requests

## Stubbing requests

Stubbing requests simply refers to the act of saying "I want all
HTTPrequests that match this pattern to return this thing". The
"thing"can be made up of a lot of different things.

First, load `crul` and enable `webmockr`

::: {.highlight}
``` {.chroma tabindex="0"}
library(crul)webmockr::enable()
```
:::

You can stub requests based on HTTP method and uri

::: {.highlight}
``` {.chroma tabindex="0"}
stub_request("get", "https://httpbin.org/get")#> <webmockr stub> #>   method: get#>   uri: https://httpbin.org/get#>   with: #>     query: #>     body: #>     request_headers: #>   to_return: #>     status: #>     body: #>     response_headers: #>   should_timeout: FALSE#>   should_raise: FALSE
```
:::

The returned object is of class `StubbedRequest`, with attributes
andaccessors - which you usually won't use yourself - although we use
theobject internally within `webmockr`. The object has a print method
thatsummarizes your stub, including the HTTP method, the URI, if you
setany patterns for query parameters, the query body, or request
headers,and whether you set any expectations on the response,
includingstatus code, body or response headers. Last, there's booleans
for whetheryou set a timeout or raise expectation (more on that below).

You can check the stub registry at any time to see what stubsyou have:

::: {.highlight}
``` {.chroma tabindex="0"}
stub_registry()#> <webmockr stub registry> #>  Registered Stubs#>    get: https://httpbin.org/get
```
:::

> protip: you can clear all stubs at any time by running
> `stub_registry_clear()`

Once we have the stub, we can then do a request with `crul`

::: {.highlight}
``` {.chroma tabindex="0"}
x <- HttpClient$new(url = "https://httpbin.org")x$get('get')#> <crul response> #>   url: https://httpbin.org/get#>   request_headers: #>     User-Agent: libcurl/7.54.0 r-curl/3.1 crul/0.5.1.9210#>     Accept-Encoding: gzip, deflate#>     Accept: application/json, text/xml, application/xml, */*#>   response_headers: #>   status: 200
```
:::

A response is returned that is of the same structure as a normal`crul`
response, but no actual HTTP request was performed. Theresponse object
is a bit different from a real HTTP response in thatwe don't have
response headers, but you can set an expectation ofresponse headers, and
even use real response headers you'veretrieved in real HTTP requests if
you like.

Once we've made a request we can take a peek into the requestregistry:

::: {.highlight}
``` {.chroma tabindex="0"}
request_registry()#> <webmockr request registry> #>   Registered Requests#>   GET https://httpbin.org/get   #>      with headers {#>        User-Agent: libcurl/7.54.0 r-curl/3.1 crul/0.5.0, #>        Accept-Encoding: gzip, deflate, #>        Accept: application/json, text/xml, application/xml, */*#>      } was made 1 times
```
:::

(the printing behavior above is manual - if you run this you'll see
oneline for each request - will make some prettier printing behavior
later)

We can see that a request to `https://httpbin.org/get` was made
withcertain request headers and was made 1 time. If we make that
requestagain the registry will then say 2 times. And so on.

You can also set the request headers that you want to match on.If you do
this the request has to match the HTTP method, the URI,and the certain
request headers you set.

::: {.highlight}
``` {.chroma tabindex="0"}
stub_request("get", "https://httpbin.org/get") %>%  wi_th(headers = list('User-Agent' = 'libcurl/7.51.0 r-curl/2.6 crul/0.3.6',                        'Accept-Encoding' = "gzip, deflate"))#> <webmockr stub> #>   method: get#>   uri: https://httpbin.org/get#>   with: #>     query: #>     body: #>     request_headers: User-Agent=libcurl/7.51.0 r-curl/2.6 crul/0.3.6, Accept-Encoding=gzip, deflate#>   to_return: #>     status: #>     body: #>     response_headers: #>   should_timeout: FALSE#>   should_raise: FALSE
```
:::

You can set the query parameters in a stub as well:

::: {.highlight}
``` {.chroma tabindex="0"}
stub_request("get", "https://httpbin.org/get") %>%  wi_th(    query = list(hello = "world"))#> <webmockr stub> #>   method: get#>   uri: https://httpbin.org/get#>   with: #>     query: hello=world#>     body: #>     request_headers: #>   to_return: #>     status: #>     body: #>     response_headers: #>   should_timeout: FALSE#>   should_raise: FALSE
```
:::

### Stubbing responses

Up until now the stubs we've created have only set what to match on,
buthave not set what to return. With `to_return` you can set response
headers,response body, and response HTTP status code. You don't match
requestson these three things, but rather they determine what's returned
in theresponse.

Here, we'll state that we want an HTTP status of 418 returned:

::: {.highlight}
``` {.chroma tabindex="0"}
stub_request("get", "https://httpbin.org/get") %>%    to_return(status = 418)#> <webmockr stub> #>   method: get#>   uri: https://httpbin.org/get#>   with: #>     query: #>     body: #>     request_headers: #>   to_return: #>     status: 418#>     body: #>     response_headers: #>   should_timeout: FALSE#>   should_raise: FALSE
```
:::

### Stubbing HTTP exceptions

Sometimes its useful in your stubs to say that you expect a particular
HTTPerror/exception.

`webmockr` has two functions for this:

- `to_raise`: raise any HTTP exception. pass in any http exception from
  the[fauxpas](https://github.com/ropenscilabs/fauxpas) package
- `to_timeout`: raise an HTTP timeout exception. this is it's own
  functionsince timeout exceptions are rather common and one may want to
  use them often

Here, with `to_raise` we pass in an HTTP exception, in this case the
`HTTPBadRequest`exception:

::: {.highlight}
``` {.chroma tabindex="0"}
library(fauxpas)stub_request("get", "https://httpbin.org/get?a=b") %>%     to_raise(fauxpas::HTTPBadRequest)#> <webmockr stub> #>   method: get#>   uri: https://httpbin.org/get?a=b#>   with: #>     query: #>     body: #>     request_headers: #>   to_return: #>     status: #>     body: #>     response_headers: #>   should_timeout: FALSE#>   should_raise: HTTPBadRequestx <- HttpClient$new(url = "https://httpbin.org")x$get('get', query = list(a = "b"))#> Error: Bad Request (HTTP 400).#>  - The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.
```
:::

With `to_timeout` a matched request to our stub will then return a
timeout error:

::: {.highlight}
``` {.chroma tabindex="0"}
stub_request("post", "https://httpbin.org/post") %>%     to_timeout()#> <webmockr stub> #>   method: post#>   uri: https://httpbin.org/post#>   with: #>     query: #>     body: #>     request_headers: #>   to_return: #>     status: #>     body: #>     response_headers: #>   should_timeout: TRUE#>   should_raise: FALSEx <- HttpClient$new(url = "https://httpbin.org")x$post('post')#> Error: Request Timeout (HTTP 408).#>  - The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.
```
:::

Check out [fauxpas](https://github.com/ropenscilabs/fauxpas) for more
information about HTTP exceptions.

## Allowing real requests

You can always disable `webmockr` by using `webmockr::disable()`, which
completelydisables mocking.

You can also allow some real requests while still using `webmockr`.

One way to allow some requests is to execute
`webmockr_allow_net_connect()`, whichdoesn't disable `webmockr`
completely - it allows real HTTP requests to bemade that have no stubs
associated.

Another way is to disallow all requests except for certain URIs
using`webmockr_disable_net_connect()`. For example, if we
run`webmockr_disable_net_connect("google.com")` no real HTTP requests
are allowedother than those that match `"google.com"`.

You can also allow only localhost HTTP requests with the
`allow_localhost` parameterin the `webmockr_configure()` function. Run
`webmockr_configure(allow_localhost = TRUE)`,and then all localhost
requests will be allowed while all non-locahostrequests will not be
allowed. `allow_localhost` works for all the localhost
variants:`localhost`, `127.0.0.1`, and `0.0.0.0`.

You can check whether you are allowing real requests
with`webmockr_net_connect_allowed()`, and you can see your `webmockr`
configuration with`webmockr_configuration()`.

## Storing actual HTTP responses

`webmockr` doesn't do that. Check out
[vcr](https://github.com/ropensci/vcr) for that.

Some have
[noted](https://quickleft.com/blog/decreasing-vcr-dependency-webmock/)
that in some cases storing actual http responses can get to be too
cumbersome (maybe too much disk space, or other reasons) - and have
reverted from using a tool like `vcr` that caches real responses to
using something like `webmockr` that only "stubs" fake responses.

There's many options for testing a library that does HTTP requests:

1.  Do actual HTTP requests
2.  Stub HTTP requests with a tool like `webmockr`
3.  Cache real HTTP responses with a too like `vcr`

## webmockr for your test suite

You can use `webmockr` for your test suite right now. Here's a quick
example of using`webmockr` with `testthat`

::: {.highlight}
``` {.chroma tabindex="0"}
library(crul)library(testthat)
```
:::

Make a stub

::: {.highlight}
``` {.chroma tabindex="0"}
stub_request("get", "https://httpbin.org/get") %>%   to_return(body = "success!", status = 200)#> <webmockr stub> #>   method: get#>   uri: https://httpbin.org/get#>   with: #>     query: #>     body: #>     request_headers: #>   to_return: #>     status: 200#>     body: success!#>     response_headers: #>   should_timeout: FALSE#>   should_raise: FALSE
```
:::

Check that it's in the stub registry

::: {.highlight}
``` {.chroma tabindex="0"}
stub_registry()#> <webmockr stub registry> #>  Registered Stubs#>    get: https://httpbin.org/get   | to_return:  with body "success!"  with status 200
```
:::

Make the request

::: {.highlight}
``` {.chroma tabindex="0"}
z <- crul::HttpClient$new(url = "https://httpbin.org")$get("get")
```
:::

Run tests (nothing returned means it passed)

::: {.highlight}
``` {.chroma tabindex="0"}
expect_is(z, "HttpResponse")expect_equal(z$status_code, 200)expect_equal(z$parse("UTF-8"), "success!")
```
:::

## Todo

There are a number of things to still get done with `webmockr`

- Integrating into `curl` and `httr` for mocking requests with those
  libraries.
- Support [multiple responses for repeated
  requests](https://github.com/bblimke/webmock#multiple-responses-for-repeated-requests)
- Allow to [specify number of times a given response should be
  returned](https://github.com/ropensci/webmockr/issues/10), [see
  also](https://github.com/bblimke/webmock#specifying-number-of-times-given-response-should-be-returned)
- Support regex patterns for URI's and [URI
  templates](https://github.com/ropensci/webmockr/issues/20)
- and probably lots more ...

## Feedback!

We'd love to get some eyes on this; to sort out problems that will no
doubt arise from real world scenarios; to flesh out new use cases we
hadn't thought of, etc.

Open an issue: <https://github.com/ropensci/webmockr/issues/new>


webmockr   webmockr is an R library for stubbing and setting expectations on HTTP requests.It is a port of the Ruby gem webmock. webmockr works by plugging in to another R package that does HTTP requests. It currently only works with crul right now, but we plan to add support for curl and httr later.

webmockr: mock HTTP requests

University of Glasgow

Roderic Page

::: {.bbpBox25151382818}
@[mikeal](http://twitter.com/mikeal){.tweet-url .username
rel="nofollow"} a little tedious. you can take OSM and then convert it
to SHP and then
[http://github.com/maxogden/shp2geocouch](http://github.com/maxogden/shp2geocouch){rel="nofollow"}[[less
than a minute
ago](http://twitter.com/maxogden/status/25151382818 "Tue Sep 21 21:03:30 +0000 2010")
via
web]{.timestamp}[[[![](http://a2.twimg.com/profile_images/1089502710/maxcropped_normal.png)](http://twitter.com/maxogden)**[max
ogden](http://twitter.com/maxogden)**  
maxogden]{.author}]{.metadata}
:::

  
  
The tweet above inspired me to take a quick look at
[GeoCouch](http://github.com/vmx/couchdb), a version of CouchDB that
supports spatial queries. This is something I need if I\'m going to
start playing seriously with CouchDB. So, it was off to [Installing and
working with GeoCouch](http://maxogden.com/), grabbing a copy of
[HomeBrew](http://mxcl.github.com/homebrew/) (yet another package
manager for Mac OS X), in the hope of installing GeoCouch. Things went
fairly smoothly, although it took what seemed like an age to build
everything. But I now have GeoCouch running. Previously I\'d been
running CouchDB using <http://janl.github.com/couchdbx/>, which launches
vanilla CouchDB. However, if you launch CouchDBX after starting GeoCouch
from the command line, CouchDBX is talking to GeoCouch.  
  
I then grabbed [shp2geocouch](http://github.com/maxogden/shp2geocouch)
to try some shape files (I grabbed some shape files from the
[IUCN](http://www.iucnredlist.org/technical-documents/spatial-data) to
play with). If you\'re on a Mac grab
[GISLook](http://jenny.cartography.ch/gislook/) to get Quick Look
previews of these files. Since I\'m new to ruby there were a couple of
gotchas, such as lacking some prerequisites (`httparty` and `couchrest`,
both installed by typing `gem install `), and there was the small matter
of needing to add `~/.gem/ruby/1.8/bin` to my path so I could find
shp2geocouch (spot the ruby neophyte). The shape file didn\'t get
processed completely, but at least I managed to get some data into
GeoCouch.  
  
![gis.png](http://lh4.ggpht.com/_Gct8lVAxKqQ/TJoj20IqwAI/AAAAAAAAAxA/DpktSGacYlg/gis.png?imgmax=800){style="display:block; margin-left:auto; margin-right:auto;"
border="0" width="400" height="349"}  
So far I\'ve been playing with the examples at
<http://github.com/vmx/couchdb>, and things seem to work. At least, the
basic bounding box queries work. I\'m tempted to play with this some
more (and get my head arounbd [GeoJSON](http://geojson.org/)), perhaps
trying to recreate the functionality of my [Elsevier Challenge
entry](http://iphylo.org/~rpage/challenge/), for which I wrote a custom
key-value database that was awfully clunky.  
  


@mikeal a little tedious. you can take OSM and then convert it to SHP and then http://github.com/maxogden/shp2geocouchless than a minute ago via web
<strong>
 max ogden
</strong>
maxogden  The tweet above inspired me to take a quick look at GeoCouch, a version of CouchDB that supports spatial queries. This is something I need if I'm going to start playing seriously with CouchDB.

Messaggi di Rogue Scholar

vcr: record and replay HTTP requests

webmockr: mock HTTP requests

GeoCouch