Added a "TestFeatureStore" #51
Conversation
… on or off with a public API.
| } | ||
|
|
||
| private void writeFeatureRep(final String key, final Variation<Boolean> variation) { | ||
| FeatureRep<Boolean> newFeature = new FeatureRep.Builder<Boolean>(String.format("test-%s", key), key) |
There was a problem hiding this comment.
This is kind of hardcoded to Boolean based flags only at the moment...
|
I think this will work pretty well. It will require changes with our new v2 API (and any time we make significant internal changes to So I'm on board with this approach. |
|
Awesome, @jkodumal what further work would you recommend to get this over the line? Are you happy with the API, javadoc, etc? |
|
I think if we make the API a little more generic, we'll reduce or eliminate the need to make API-breaking changes to this class with v2. I'll add some comments where I think the API should be tweaked a bit. |
|
Actually, I think this will be fine. I think when v2 and multivariates come out we can extend this API and we won't necessarily need to modify it in breaking ways. I can't guarantee that though-- it might be the case that you'll need to make some minor tweaks to usages of this when v2 rolls out. |
make a few more classes package-private
2 participants
So running off the tail of #50 - this is a slightly different approach which doesn't expose reps. Using something like this
TestFeatureStorewould allow users to configure theLDClientin a way that allows them to internally creates to be 100% "on" or "off" without any direct dependency on the rulesets coming from LD (e.g. configure it to also be .stream(false), etc).This allows for runtime flipping of the flag values (with a reference to the configured
TestFeatureStore) in test environments (e.g. perhaps where mocking is not viable), amongst other possibilities which don't want to depend on an external source of the flag rulesets. The primary desired comes from, for example, integration environments where rapidly changing the flag values via the API would be expensive.The API / implementation is a bit rough and I want to open it up as is for discussion to see if this seems like a sensible way to go (especially with future incoming changes, etc) - or perhaps of a better alternative altogether?