Are there any bogus credentials one can use for unit testing?
I'd like to add unit tests which verify social login via One All is working. On the other hand I don't want to put o my real oneall credentials in the test code. Is there a site/public/private keys designed for this? What abou bogus users for numerous social login providers? I'd also hate to have to put credentials for those in my test code. If no such test credentials/users exist, how are other folks doing unit/integrated testing for oneall-related stuff?
Welcome!
Please sign in to your OneAll account to ask a new question or to contribute to the discussions.
Please click on the link below to connect to the forum with your OneAll account.
Information
Products & Services
Categories
- 2.2K All Categories
- 1.1K General
- 1.1K Questions
- 46 Suggestions
- 592 Implementation
- 10 Single Sign On
- 16 LoudVoice
- 658 Turnkey Plugins
- 42 Drupal
- 33 Joomla!
- 21 Magento
- 22 myBB
- 84 Opencart
- 125 phpBB
- 39 PrestaShop
- 31 Simple Machines Forum
- 9 Vanilla
- 17 vBulletin
- 8 WHMCS
- 221 WordPress
- 6 ZenCart
Answers
Good question. This is not available (maybe a good idea though), however you can:
- add another Oneall application to your Oneall account (with specific credentials), restricted to your test site,
- configure new social network applications for this app, but restricting the access to a set of authorized developer (some social network provide this, not all)
- create a specific social account?
That also depends on what you are testing.
If it is access to the API, after login, then you can re-use a user token (with the test Oneall app).
There are probably other things to consider. But we can start a conversation here.
Regards
I merely need to test that social login works for my site, I don't need to test the rest of the api.
What you said makes sense. I *think* I can combine this with storing credentials in env vars. This should work both for local testing, and I just checked, and it appears that the env vars associated with a repo on travis-ci are only viewable if you are the *owner* of that repo, so that should work as well.
Here's my plan,
1) setup another 'testing' application with my oneall account, restricted to localhost and *.travis-ci.org
2)Probably just configure a single social network for it.
- You wouldn't happen to know offhand which social networks allow restricting access to a set of authorized developers, would you? If not I'll probably try google first
3) create a social acct with whatever authentication provider I setup
4) store both the credentials for my 'testing' oneall application and social acct username/pass using env vars.
I'm working on other stuff currently, so probably won't be able to test it for a few days. I was asking this question in advance as I'm one of the contributors to the django-oneall and pyoneall projects, and I was trying to figure out how to add some more unit tests for those projects.
Do you think this approach sounds reasonable?
-Scott
Thanks for the info (and your contributions to the Python apps
Yes, that sounds good. Please post back on any success/problems, as it may interest others here.
For 2), Facebook allows your app to be in development mode only, and define tester accounts that can access the app only in this mode (https://developers.facebook.com/docs/apps/security).
So, you could add the test social account created as a Facebook App tester.
Regards
PS: are you related to the educational project Rimac? If so: neat.
Also, I discovered that you can put encrypted credentials in the .travis.yaml file so I'll look into that as well.
Yes, I'm working on the Rimac project. The current django-oneall maintainer (he's looking for someone to take over) was nice enough to add a feature which allows anonymous logins using oneall. If the setting is enabled, the oneall token is converted to to a pseudo random (same everytime) username, and none of the other data received about the user is stored. This is important to us as since we're doing experiments with students, and we need anonymity.
Regarding django-oneall / pyoneall (whichever project it turns out is best to place the unit tests), I plan to test the whole API - when I get around to it.
Thanks for the help again, I'll keep in touch.
if you want to takeover the django-oneall project, then please go on!
We offer free plans to everybody who creates a plugin for using OneAll
Regards,
I'm still working on testing this, err mainly thinking about it. I think to test this, I'll actually need to use Django's LiveServerTestCase instead of simply TestCase and use selenium. I seem to remember that the Safari selenium driver has issues with pop-ups. Not sure if that's a Safari issue or merely a problem with the emulators on BrowserStack/SauceLabs. I know that there is a way with oneall to use a redirect/callback rather than a popup, but I *might* actually need to add a feature to django-oneall to support this.