Adding test data store and specs

[pierrel]

I found this useful for setting a global green light for testing purposes.

[tfausak]

Thanks for opening this pull request! I have a question about the motivation. Are you trying to avoid stoplights changing state during tests? If so, there are a few ways to do that now.

1. Always generate a unique name.

   let(:stoplight) do
    Stoplight("test-#{rand}") { ... }
   end

2. Reset the data store before each test.

   before do
    Stoplight::Light.default_data_store = Stoplight::DataStore::Memory.new
   end

Those aren't exactly the same, of course. They can change state during a test. But that's typically what I want anyway.

Do either of those approaches work for your use case?

[pierrel]

@tfausak those are actually some great recommendations. I'd been scratching for a while on how to use the current tools provided to get around Stoplight locking up. Had I known of those I may not have tried this approach.

That being said though I like this approach because it makes it more explicit that Spotlight is in test mode and moves the configuration to a single place. This also gets around the (admittedly uncommon) use case where a single test scenario could exhaust the light threshold by itself. I also like using the Stoplight interface directly instead of going the route of your first suggestion.

My original thought was that something like Stoplight.default_threshold = -1 existed. Where -1 meant ∞. Anyway this approach is actually easily org-extensible without modifying this code base so I would completely understand if you didn't want to take it into the source. Anyway we've been loving this product here at Blurb!

[tfausak]

I agree that it's nice to be explicit about being in test mode. Unfortunately, I think we have different definitions of test mode. I sometimes want to test that stoplights flip after a certain number of tries.

If a single test case could change a stoplight's state and you don't want that, you could increase the threshold. Or you could lock that light green. Both are explicit about what you want and don't require a custom data store.

I would argue that generating unique names is in fact using the Stoplight interface directly. Names are a core part of Stoplight and having unique names is a good way to make sure you don't accidentally inherit some state that you don't want.

We've actually thought about negative thresholds before. Have a look at #37 for some discussion. This is the relevant bit:

I think we should disallow non-positive thresholds. A threshold of 0 is basically STATE_LOCKED_RED and a threshold of -1 is STATE_LOCKED_GREEN.

The constant names have changed (Stoplight::State::LOCKED_RED), but the sentiment is the same. I think Stoplight already provides enough tools to handle working with test suites.

[pierrel]

Thanks so much for the feedback. I think this approach works for us and without any real extending of the source.

[tfausak]

I'm glad I was able to help! Are there any changes we could make to the documentation to make it easier to use Stoplight in tests?

[pierrel]

I would add a section with both of your recommendations.