Allow dynamic override of arg provider in testing

[JJosephttg]

In testing, we may want to utilize the existing arg that is used inside of a widget when testing with mocks/overridden providers.

Is there some way/something we can introduce to pass the argument being created with so that when the provider is created, we can override with a different implementation function?

For example, using the number provider:

const numberProvider = Provider.withArgument((context, arg) => arg * 2);

...

testWidgets(..., (...) {
    ...
    ProviderScopeOverride(
          overrides:[numberProvider.overrideWithValue((arg) => arg * 4)]
          child: ...
    );

// Output with numberProvider(1) would be 4, not 2
});

Part of what we are testing could be that the argument provided to it is correct and produces a specific output

[manuel-plavsic]

Can you explain to us what is your main goal with this? Can you give us a concrete example? You don't have to be very detailed.
Like, would you like to have custom logic for specific use cases, e.g., login in tests does not actually call the main backend API for user authentication; instead, it uses an alternative backend API or you work with some hardcoded data?

[JJosephttg]

So biggest concern that I would potentially run into is if I have another dependency that I have mocked, and I still want to use the real thing, but inject specific dependencies into a provider that also depends on an argument. Since the creation function doesn't get executed in the arg provider for a override, you may miss initialization logic that you still need in some respect or you may depend on what that arg is to tell what provider is used in a specific situation.

For example, maybe I have a userEmailService that depends on a mocked email client, and also maybe takes a user ID as an argument or something. I want to make sure the email that gets sent goes to the right user. I want to use the real email service, while still relying on my mocked client to tell me whether an email was sent to the right person. Not an actual case I have but just an example. In this case I need to use the arg, and I also may want to continue some initialization as the same, but rely on a different mechanism to create the provider so it maintains how it would normally work.

I may also depend on several separate instances of the same provider with different arguments. Not sure if that is possible, but if I need the email service for 2 separate users, I need 2 separate instances/ones passed with different arguments. I may also need to verify test case wise that the argument passed is correct if it leaves the system depending on how its used

[manuel-plavsic]

I am very busy until March 20, so I will just give you a workaround for now, but I will come back to you later. Maybe @nank1ro finds time sooner than that to properly answer you.

You could make the argument a tuple, where the first tuple element is the "actual argument" and the second one is an enum (with two variants A and B). In the body of the provider, you then handle both variants A and B. When you insert the provider in the widget tree, you give an instance of variant A in the tuple. In the override, the argument is a tuple with variant B.

When you do injection, you mainly rely on the first element: numberProvider.of(context).value.$1. But you could also rely on the enum variant $2 (e.g., if you want to handle the logic of a different provider in multiple ways based on numberProvider's variant).

Hope this helps for the moment.

[manuel-plavsic]

Small update: I managed to implement this locally, using the right approach. I'll open a PR tomorrow.

[manuel-plavsic]

I opened a new pull request (#40). @JJosephttg is the approach with overrideWithProvider (for both Provider.withArgument and the normal Provider) what you had in mind?