I need to automate interaction with a website that is initially protected with ReCaptcha. Can I initially manually log in to the website and solve 2FA, then hand-over the existing manually initiated session to the testing application to automatically run through the website tests with my manually authenticated session?
-
What language are you coding in?– HaCCommented Dec 3, 2017 at 5:59
-
Python, preferably.– EnemyBagJonesCommented Dec 3, 2017 at 17:41
-
1Just for reference, for connecting existing browser session, I believe the below two existing question/answer will be useful: https://stackoverflow.com/questions/44277119/how-to-connect-slenium-webdriver-to-existing-firefox-chrome-browser-session https://stackoverflow.com/questions/44186595/connecting-selenium-webdriver-to-an-existing-browser-session– AnandCommented Dec 8, 2017 at 19:11
2 Answers
I think it should be the other way around, letting the test hand it over to a manual users for a while:
- Start the Selenium test to open browser and goto CAPTCHA page
- Write a wait that waits for an element that would be shown after the CAPTCHA is completed. (Make sure this wait has a large timeout, maybe also enlarge the default timeouts. Be sure to reset default timeouts after your wait, if you change implicit wait your tests could wait for minutes when something is broken.)
- Fill in the CAPTCHA manually
- The test will see the element found and continue the test instantly, as it will poll for the element every 500ms by default.
Aslong the test is waiting for something you can just use the browser as normal.
Some reads:
- Working with timeouts: http://toolsqa.com/selenium-webdriver/wait-commands/ (Guess the fluent-wait example is good to change from 30 seconds to 15 minutes, making sure you have the time to finish the CAPTCHA)
- Official documentation on timeouts: http://www.seleniumhq.org/docs/04_webdriver_advanced.jsp
-
Perfect, thanks Niels. I'll give this approach a shot. Commented Dec 3, 2017 at 17:42
Firstly, this is maybe be a smell that your application is not built with a testability mindset.
In the Automation environment:
1 - This feature should be removed;
or
2 - The user should be automatically log by sending a token generated uniquely by the application, identifying therefore the user.
There are ways of working around the issue, but this way you would still have an application difficult to test and probably your tests would take longer to run.
Attack the disease, not the symptoms.
-
Good point - but sometimes in dysfunctional situations the testing team can't perfectly dictate the testing environment, or a quick hacky approach is needed to test the 'internals' w/o disabling the initial security. Generally speaking though I think you are very right. Commented Dec 3, 2017 at 17:43