LG-11748 new spec for IPP opt-in flag variations

[racingspider]

With multiple opt-in flags available, we want to test multiple variations of flag values.

🎫 Ticket

LG-11748

🛠 Summary of changes

Add new spec file, split some of the logic it requires into helper files.

[gina-yamada]

@racingspider Do we need to add allow(IdentityConfig.store).to receive(:in_person_proofing_opt_in_enabled).and_return(false) to all of the other ipp feature specs? I am not sure if they'd fail once we flip the flag.

[racingspider]

@racingspider Do we need to add allow(IdentityConfig.store).to receive(:in_person_proofing_opt_in_enabled).and_return(false) to all of the other ipp feature specs? I am not sure if they'd fail once we flip the flag.

@gina-yamada I'm nearly 100% sure yes - one of the earlier tests I did made it clear that changing the application yml file would cause an avalanche of failures. I think we should make another ticket to handle that as well.

[JackRyan1989]

Looks good! Small (nit-picky) changes suggested.

[gina-yamada]

I think you linked the wrong ticket number in your description. It should be LG-11748

[gina-yamada]

@racingspider Do we need to add allow(IdentityConfig.store).to receive(:in_person_proofing_opt_in_enabled).and_return(false) to all of the other ipp feature specs? I am not sure if they'd fail once we flip the flag.

@gina-yamada I'm nearly 100% sure yes - one of the earlier tests I did made it clear that changing the application yml file would cause an avalanche of failures. I think we should make another ticket to handle that as well.

Does it make sense to create a new ticket for additional specs to handle this PR? Then, keep LG-11748 as is?

[gina-yamada]

@racingspider Do we need to add allow(IdentityConfig.store).to receive(:in_person_proofing_opt_in_enabled).and_return(false) to all of the other ipp feature specs? I am not sure if they'd fail once we flip the flag.

@gina-yamada I'm nearly 100% sure yes - one of the earlier tests I did made it clear that changing the application yml file would cause an avalanche of failures. I think we should make another ticket to handle that as well.

Does it make sense to create a new ticket for additional specs to handle this PR? Then, keep LG-11748 as is?

Cancel my suggestion of a new ticket. We have a stub ticket for specs that we can use I bet. We still need to refine it so learnings out of this PR/discussion can drive the requirements at our next refinement session