README.md in stub_requests-0.1.1 vs README.md in stub_requests-0.1.2

@@ -14,13 +14,15 @@
 
 <!-- MarkdownTOC -->
 
 - [Installation](#installation)
 - [Usage](#usage)
+  - [Register service endpoints](#register-service-endpoints)
+  - [Stubbing service endpoints](#stubbing-service-endpoints)
+  - [Metrics](#metrics)
 - [Future Improvements](#future-improvements)
   - [API Client Gem](#api-client-gem)
-  - [Debugging](#debugging)
 - [Development](#development)
 - [Contributing](#contributing)
 - [License](#license)
 - [Code of Conduct](#code-of-conduct)
 
@@ -52,10 +54,13 @@
 
 To use the gem we need to register some service endpoints. In the following example we are connecting to a rails inspired service.
 
 The naming of the `service_id` and `endpoint_id`'s is irrelevant. This is just how we look things up in the registry.
 
+<a id="register-service-endpoints"></a>
+### Register service endpoints
+
 ```ruby
 StubRequests.register_service(:google_ads, "https://api.google.com/v5") do
   register(:index, :get, "ads")
   register(:show, :get, "ads/:id")
   register(:update, :patch, "ads/:id")
@@ -64,10 +69,13 @@
 end
 ```
 
 Now we have a list of endpoints we can stub.
 
+<a id="stubbing-service-endpoints"></a>
+### Stubbing service endpoints
+
 ```ruby
 StubRequests.stub_endpoint(:google_ads, :index)
             .to_return(code: 204, body: "")
 
 # This is the equivalent of doing the following in WebMock
@@ -75,12 +83,10 @@
 
 WebMock.stub_request(:get, "#{Settings.google_ads_base_uri}/ads")
        .to_return(status: 204, body: "")
 ```
 
-So far so good but not much of a gain yet. The real power comes when we don't have to interpolate a bunch of URLs all the time.
-
 ```ruby
 StubRequests.stub_endpoint(:google_ads, :update, id: 1) do
   with(body: request_body.to_json)
   to_return(code: 200, body: response_body.to_json)
 end
@@ -91,16 +97,23 @@
 WebMock.stub_request(:patch, "#{Settings.google_ads_base_uri}/ads/#{id}")
        .with(body: request_body.to_json)
        .to_return(status: 200, body: response_body.to_json)
 ```
 
-First of all we reduce a lot of duplication.
+This reduces the need to spread out URI's in the test suite without having to resort to shared examples.
 
-Imagine a code base with thousands of stubbed request. You always have to look at the defined URL to understand which request is actually being called.
+<a id="metrics"></a>
+### Metrics
 
-Madness!!
+Metrics collection are by default turned off. It can be turned on by the following code.
 
+```ruby
+StubRequests.configure do |config|
+  config.record_metrics = true
+end
+```
+
 <a id="future-improvements"></a>
 ## Future Improvements
 
 <a id="api-client-gem"></a>
 ### API Client Gem
@@ -108,14 +121,9 @@
 Since we have a service + endpoint registry, I was thinking it might make
 sense to make this into an API client. Not sure yet, maybe this will become multiple gems in the future so that someone can pick and choose.
 
 Anyway, the idea was to provide endpoint calls in production and stubbed
 requests in tests using the same registry.
-
-<a id="debugging"></a>
-### Debugging
-
-I want to provide information about where a request stub was created from. In the project I am currently working this would have saved me a days work already.
 
 <a id="development"></a>
 ## Development
 
 After checking out the repo, run `bin/setup` to install dependencies.