From 029b5481fe4e5a729d4ac568eee8a7143b4e0ed1 Mon Sep 17 00:00:00 2001 From: Ryan Laughlin Date: Mon, 18 May 2020 17:41:58 -0400 Subject: [PATCH] Consolidate #testing section of README --- README.md | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index 60b8d2f..86d1fad 100644 --- a/README.md +++ b/README.md @@ -40,7 +40,6 @@ See the [Backing & Hacking blog post](https://www.kickstarter.com/backing-and-ha - [Testing](#testing) - [How it works](#how-it-works) - [About Tracks](#about-tracks) -- [Testing](#testing) - [Performance](#performance) - [Motivation](#motivation) - [Contributing](#contributing) @@ -396,6 +395,10 @@ end ## Testing +A note on developing and testing apps using Rack::Attack - if you are using throttling in particular, you will +need to enable the cache in your development environment. See [Caching with Rails](http://guides.rubyonrails.org/caching_with_rails.html) +for more on how to do this. + ### Disabling `Rack::Attack.enabled = false` can be used to either completely disable Rack::Attack in your tests, or to disable/enable for specific test cases only. @@ -441,13 +444,6 @@ can cleanly monkey patch helper methods onto the `Rack::Attack.track` doesn't affect request processing. Tracks are an easy way to log and measure requests matching arbitrary attributes. - -## Testing - -A note on developing and testing apps using Rack::Attack - if you are using throttling in particular, you will -need to enable the cache in your development environment. See [Caching with Rails](http://guides.rubyonrails.org/caching_with_rails.html) -for more on how to do this. - ## Performance The overhead of running Rack::Attack is typically negligible (a few milliseconds per request),