feat: Allow override_flag testutil to set different checks #480
Conversation
Up until now, the `override_flag` test util was only useful to completely activate or deactivate a flag. It didn't allow to provide more customization for all the internal checks it makes, like evaluating if the request user is authenticated or staff. This change provides that functionality, without breaking the current API, to avoid breaking changes. Now, users can provide more granular arguments to `override_flag`, for a more flexible flag testing. Closes jazzband#439.
There was a problem hiding this comment.
What's the use case for this? It seems the user of this functionality will ultimately either test waffle or the test itself.
For example, what does it mean to enable a flag for 25% in an automated test? Typically you want to test behavior when the flag is active vs. inactive. Setting a 25% rollout will result in flaky tests. This will be a footgun for potential users.
That user override use case is solved by instantiating the flag in the test: waffle.get_waffle_flag_model().objects.create(name='foo', everyone=None, superusers=True). However, flags are created either by migration or manually. If you create them in your test, you're really only testing your tests. If you run migrations in your test to setup the flag, your tests don't need overrides.
Flagged code doesn't care about the conditions that resulted in the flag's active state, but the state itself.
|
Closing due to inactivity. |
Up until now, the
override_flagtest util was only useful to completely activate or deactivate a flag. It didn't allow to provide more customization for all the internal checks it makes, like evaluating if the request user is authenticated or staff.This change provides that functionality, without breaking the current API, to avoid breaking changes. Now, users can provide more granular arguments to
override_flag, for a more flexible flag testing.Closes #439.