8000 Improve test support · Issue #1197 · togglz/togglz · GitHub
[go: up one dir, main page]
Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Improve test support #1197

Open
hohwille opened this issue Jun 28, 2024 · 1 comment · May be fixed by #1198
Open

Improve test support #1197

hohwille opened this issue Jun 28, 2024 · 1 comment · May be fixed by #1198

Comments

@hohwille
8000 Copy link

Quote from your website:

One of the mission statements of Togglz is that it should be easy to integrate into applications.

In general I love togglz for its simplicity so thank you for making it.
However, sorry to be frank but I would clearly state that for testing this "mission statement" definitely does not apply
Search the web for "IllegalStateException: Could not find the FeatureManager."
I do not want to be forced to add togglz test dependency to all my modules and pollute all my tests with stuff like @AllDisabled(MyFeature.class).

IMHO you could solve this way smarter for the 95% case.
This example is from your website:

public enum MyFeatures implements Feature {

    @EnabledByDefault
    @Label("First Feature")
    FEATURE_ONE,
    
    @Label("Second Feature")
    FEATURE_TWO;
    
    public boolean isActive() {
        return FeatureContext.getFeatureManager().isActive(this);
    } 
}

So why can't togglz work in a way that without any configuration this is just giving me the defaults so that FEATURE_ONE is active (@EnabledByDefault) and FEATURE_TWO is not (in JUnit tests)?
In case I want something else, I am happy to add custom JUnit dependencies and magic annotations.
I just introduced Togglz to a project with million lines of code and 600 maven modules.
Now with more components using feature-toggles all the existing tests fall apart.

I am fully aware that my "feature request" would need some magic fallback for testing in the productive togglz code.
Feel free to require some environment variable that developers could somehow set crosscutting via surefire, spring or whatever frameworks involved if you think there is no other way.
Also feel free to spam the logs with aggressive warnings if togglz is not configured and decides to fall back to this test mode since it somehow assumes it is currently running in a JUnit setup.
All is doable and has already been done by other Java libs.
IMHO this would increase your UX for developers significantly. Thanks for taking care.
@hohwille
Copy link
Author
hohwille commented Jun 28, 2024 •
edited
Loading

I did a small analysis of your code and what could be done to implements this:
You are using ServiceLoader for FeatureManagerProvider:

togglz/core/src/main/java/org/togglz/core/context/FeatureContext.java

Line 90 in dd9f4b3

Iterator<FeatureManagerProvider> providerIterator = ServiceLoader.load(FeatureManagerProvider.class).iterator();

So maybe ignoring my concern about a test-dependency that needs to be added and that could be solved by adding it to the aggregator/parent POM the easiest fix would IMHO be to create yet another togglz module for testing.
This could define src/main/resources/META-INF/services/org.togglz.core.spi.FeatureManagerProvider pointing to such a fallback implementation that simply uses reflection to get the activity from the feature in case of an enum as described.
Only problem would be for modules that have this test-dependency but also the runtime dependency needed for production use since then in JUnits both might want to provide a FeatureManagerProvider. Since you already support weighted sorting this could be solved easily such that the Test-Implementation always wins. WDYT?
Also this new test module could contain a static hack that provides direct access to dynmically enable or disable features during the JUnit test for the edge-cases. This would allow a test-integration without the need to bundle against the actual test-framework JUnit (4 vs. 5 and what may come, there is also TestNG, etc.) and no need for questionable annotations like @AllDisabled.

hohwille added a commit to hohwille/togglz that referenced this issue Jun 28, 2024
@hohwille
togglz#1197: advanced test support
c455ffe
hohwille added a commit to hohwille/togglz that referenced this issue Jun 28, 2024
@hohwille
togglz#1197: add ability to register features on setup
c40ab5e
@hohwille hohwille linked a pull request Jun 28, 2024 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

#1197: advanced test support hohwille/togglz
1 participant
@hohwille
0