Skip to content

(feat): Feature Management isFeatureEnabled Listener #271

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 19 commits into from
Apr 22, 2019

Conversation

mnoman09
Copy link
Contributor

@mnoman09 mnoman09 commented Mar 8, 2019

Summary

  • Introduction of OnDecision Notification Listener.
  • Returning default feature variable value if featureEnabled is false.
  • Implemented onDecisionListener and added unit tests in:
  • is_feature_enabled
  • get_enabled_features

##Ticket:
OASIS-4228

@coveralls
Copy link

Pull Request Test Coverage Report for Build 901

  • 58 of 61 (95.08%) changed or added relevant lines in 4 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.2%) to 89.201%

Changes Missing Coverage Covered Lines Changed/Added Lines %
core-api/src/main/java/com/optimizely/ab/notification/DecisionInfoEnums.java 10 11 90.91%
core-api/src/main/java/com/optimizely/ab/notification/NotificationCenter.java 17 19 89.47%
Totals Coverage Status
Change from base Build 892: 0.2%
Covered Lines: 2701
Relevant Lines: 3028

💛 - Coveralls

@coveralls
Copy link

coveralls commented Mar 8, 2019

Pull Request Test Coverage Report for Build 974

  • 47 of 47 (100.0%) changed or added relevant lines in 2 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.2%) to 89.388%

Totals Coverage Status
Change from base Build 972: 0.2%
Covered Lines: 2788
Relevant Lines: 3119

💛 - Coveralls

Copy link
Contributor

@aliabbasrizvi aliabbasrizvi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please point me to where confirmation is happening that notification listener is being called with correct parameters

@@ -24,7 +24,6 @@
import javax.annotation.Nonnull;
import java.util.Map;


Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like an unnecessary change.

return key;
}
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit. remove extraneous line

* onDecision called when an activate was triggered
*
* @param type - The notification type.
* @param userId - The userId passed into activate.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please update the docstrings here as mentioned in the other PR.


verify(mockEventHandler, times(2)).dispatchEvent(any(LogEvent.class));

assertTrue(optimizely.notificationCenter.removeNotificationListener(notificationId));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where is the check for notification listener being called with correct params happening?

*/
@Override
public final void notify(Object... args) {
assert (args[0] instanceof String);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aliabbasrizvi here we added multiple assert checks which will throw exception if invalid arguments are passed and it will make sure that correct arguments are passed. so I think we dont need to add this in unit tests

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should have type specific checks i.e. for type: experiment we should check decisionInfo has correct experiment and variation key. Similarly for type: feature we should check decisionInfo has correct data.

Can you point me to where such assertions are happening? If not, then we have incomplete tests.

mnoman09 and others added 4 commits April 8, 2019 10:35
…Listnr

# Conflicts:
#	core-api/src/main/java/com/optimizely/ab/Optimizely.java
#	core-api/src/main/java/com/optimizely/ab/notification/DecisionNotificationListener.java
#	core-api/src/main/java/com/optimizely/ab/notification/NotificationCenter.java
#	core-api/src/test/java/com/optimizely/ab/OptimizelyTest.java
#	core-api/src/test/java/com/optimizely/ab/notification/NotificationCenterTest.java
@mnoman09 mnoman09 requested a review from aliabbasrizvi April 18, 2019 14:26
testDecisionInfoMap.put(FEATURE_KEY, validFeatureKey);
testDecisionInfoMap.put(FEATURE_ENABLED, true);
testDecisionInfoMap.put(SOURCE, FeatureDecision.DecisionSource.ROLLOUT);
testDecisionInfoMap.put(SOURCE_INFO, new HashMap<>());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit. fix indentation

.withFeatureEnabled(featureEnabled)
.withSource(decisionSource)
.withExperimentKey(sourceExperimentKey)
.withVariationKey(sourceVariationKey)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May be remove these 2 build options and replace with withSourceInfo option which takes SourceInfo object.

You can then define 2 implementations SourceInfo. 1 for rollout and 1 for feature test and then use a get method on them to get the source info that you build in the builder here. That may be a better way to structure this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you suggesting to make methods of get source info in optimizely or in DecisionNotification.java?
By the way I think current implementation is much simpler and fully utilizing builder pattern.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am suggesting something like:

public interface SourceInfo {
  HashMap<String, Object> get()
}

public class FeatureTestSourceInfo implements SourceInfo {
}

public class RolloutSourceInfo implements SourceInfo {
}

This may allow us to hopefully add more SourceInfo options in the future.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussed offline. This will happen in a follow up.

@mnoman09 mnoman09 requested a review from aliabbasrizvi April 22, 2019 05:36
@aliabbasrizvi aliabbasrizvi dismissed mikecdavis’s stale review April 22, 2019 23:37

Synced with Mike offline. Going to go ahead with this.

@aliabbasrizvi aliabbasrizvi merged commit 6198fd6 into master Apr 22, 2019
@aliabbasrizvi aliabbasrizvi deleted the mnoman/isFeatEnabledNotif branch April 22, 2019 23:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants