Add QueryableFake gateway

[christopherdcunha]

Description

This change adds a fake gateway that can be queried programatically.

Motivation and Context

This allows my functional tests to receive tokens and complete the 2FA flow.

How Has This Been Tested?

This has been tested via the unittests in this PR and a functional test similar to the one in the docstring of the QueryableFake class.

Screenshots (if appropriate):

Documentation configuration.html#general-settings

Documentation configuration.html#queryablefake-gateway

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

[codecov]

Codecov Report

Merging #293 into master will increase coverage by 0.06%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master    #293      +/-   ##
=========================================
+ Coverage   96.54%   96.6%   +0.06%     
=========================================
  Files          39      39              
  Lines        1648    1681      +33     
  Branches      116     118       +2     
=========================================
+ Hits         1591    1624      +33     
  Misses         35      35              
  Partials       22      22

Impacted Files	Coverage Δ
two_factor/gateways/fake.py	100% <100%> (ø)	⬆️
tests/test_gateways.py	100% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 268c0d6...cfc695d. Read the comment docs.

[moggers87]

I've got a few comments and questions, especially around how the new gateway would work with multiple tests.

Thanks for adding to the documentation (not enough people do that!)

[moggers87]

The new gateway is not a singleton. I know what you're trying to say here (sms_tokens and call_tokens are initialised when the class is created not when an object is instantiated) but "singleton" would mean that things like QueryableFake().sms_tokens = {} would affect other instances of QueryableFake because there would only be one instance of the class.

[moggers87]

More tests please. E.g. do call_tokens and sms_tokens get reset properly after each testcase?

[christopherdcunha]

Thanks for the review @moggers87 - I've added commit cfc695d which addresses the issues you mentioned (or tries to at least). If you are happy with the changes, then I'll squash the commit and push.

[Bouke]

If this is merged, the text "Currently two gateways are bundled:" no longer holds.

[Bouke]

An alternative would be to just use fixed tokens instead. This would simplify the tests, while allowing the same use case. For example, it could work e.g. like this:

• 000000 -> valid token
• 000001 -> invalid token

[christopherdcunha]

Thanks for the review @Bouke

RE: The fixed tokens approach.

I think that you're suggesting an approach where PhoneDevice.verify_token(self, token) will simply return token == '000000'. And a test case would simply check if gateways.fake.Fake.send_sms(device, token) was called.

Is my understanding correct?

[dopry]

@Bouke @christopherdcunha, is this still something worth pursuing? It sounds like there may need to be some consensus about whether this is the best approach to testing.

[christopherdcunha]

@Bouke @christopherdcunha, is this still something worth pursuing? It sounds like there may need to be some consensus about whether this is the best approach to testing.

Agreed. I personally prefer/use the approach I've suggested here, but I'm totally happy to close this PR if it doesn't make sense for the broader "library user base".