I need to automate an end to end test that include purchase an order with PayPal. This test includes validate some elements in a screen that appears once the order is purchased.
I'm currently trying with cypress.io.
I know cypress recommend against visiting 3rd party sites but I need to interact with PayPal in this test.
I have not been able to deal with it.
Is there any workaround to interact with the PayPal popup when using cypress.io?
Unless you are testing PayPal itself, you should avoid doing this. Cypress make these recommendations for a reason. You run the risk of mistakenly doing financial transactions, and PayPal won't take kindly to you running your app tests against their live server.
If you really need to test how your app works, you should mock up the PayPal API's, so that you can make sure everything works as expected. This might be quite a bit of work to make it behave properly.
If you want to test out some kind of iframe interactivity with PayPal, it's going to be difficult, as the security layer in the browser is likely to prevent cross-domain activity.
Related
I don't know if this is unusual, but I'm wondering if I should test my automation that uses Selenium (written in Python).
Basically, I have to login and perform some actions in an old web application that doesn't have public APIs, so this is the only way to automate what I need to do. It's an application from my city hall to create tax receipts.
But I couldn't think of a way to test if my code will work. Right now it's working, but I'm refactoring a few things and thought that there could be something I can do to test if things will continue to work as they should. The problem is that it's a critical automation, and it's only used once per month; I don't have access to any kind of sandbox environment. What I usually do if I need to run the automation is to create a tax receipt of my own company, with $1 value, and then I just cancel it, but it's... weird.
One thing that crossed my mind was to perform the automation one time and in every step just save the whole HTML. Then, I could write tests and mock the page clicks / navigation; instead of loading the URL, it would load the HTML file.
I know it wont't be 100%, in production there can be errors that I haven't foreseen. But then I can update my tests to include these corner cases as they happen. Anyone had experience with this type of thing before?
We have a number of Google Sheets accounts specifically dedicated for use by test automation. Our tests use Selenium to automate the Google auth flow and then the rest of the test flow.
Starting Friday (6 Oct 2017) we are seeing Google sometimes inserts captchas into the auth flow. We don't see any consistency in which tests, or which test machines, get captchas and which don't. In some runs we see almost every test encounter captchas, in other runs we see only a few get captchas. We never see captchas when manually executing the test scenarios, and manually solving the captchas as the tests run does not prevent future captchas.
We've seen this sporadically in the past, and it has always gone away on its own. This time it appears to be sticking around.
Given the whole point of these test accounts are to be used by bots, and the whole point of captcha is to prove the user is not a bot, we looked through the settings for the Google accounts for something along the lines of "Never captcha this account" and didn't see any likely candidates. Our searches of StackOverflow and the web for variants of "[google-oauth] [recaptcha] whitelisting" and the like haven't turned up anything beyond "The whole point of captcha is to not be automatable, duh", which we already knew and doesn't help us get our tests running.
Is there a way to whitelist these accounts to never trigger captcha?
Here's Google's official answer:
"There isn't. If you're using a gsuite domain for your test accounts, however, you can run your own identity provider to handle the auth. Not entirely sure if that avoids it 100% of the time though."
I am sick of the absolute pile of rubbish that is the paypal sandbox for numerous reasons but one thing that is annoying me especially at the moment is the login cookie length. It lasts all of 5 minutes before you have to log in again. You lose the page you were on and end up back at the dashboard after punching in your password for the 500th time that day.
I am testing reference transactions (another completely embarassing sandbox implementation) and whenever I go to check or change something in the account I am using to pay I am logged out.
Is there any way to force it to keep me logged in for longer?
if you are logging into another account to pay, this is why you are being logged out. try using another browser, or private browsing to keep your logins separate.
I work with the sandbox every day and I don't have any issues in general. Not sure why you would be talking so badly about it.
The session thing is something PayPal does (like any financial website) to protect people. Yes, it's the sandbox, but it's meant to simulate the live PayPal site, so that session will act the same.
As for your comments about reference transactions, I guess you'll need to expand on that. I've thoroughly tested reference transactions in the sandbox for numerous projects and have never had any issues with it.
One thing I could recommend that would help with typing in the password over and over (as well as help you maintain good password standard practices in general) is to use LastPass. You'll never have to type a password again.
Another option would be to setup a local solution using the TransactionSearch and GetTransactionDetails APIs. For example, I've started something like that with my PayPal Glass project, which is essentially replicating the PayPal interface with my PHP class library. Notice that I don't have any sign in protection on that at all, so it never times out or anything.
It's a little more effort up front, but you can save lots of time in the future with projects like you're working on. If you're working with PHP you could grab that PayPal Glass project from GitHub and just use it with your own sandbox.
I've seen different documentation on various forums and site on different ways of using Paypal api, here is a pretty useful link: https://cms.paypal.com/us/cgi-bin?cmd=_render-content&content_ID=developer/e_howto_api_ECOnMobileDevices&bn_r=o/, My question is a little different i do not want to use any of the Paypal libraries offered to us in my app, this is the link to libraries:https://www.x.com/developers/paypal/documentation-tools/sdk , I also do not want to gather any personal information, I want Paypal to take care of everything. So in other words I want to be able to open up a UIWebview to the Paypal's mobile site if possible (or if not the regular site will work) have to user log in with his credential or he can use the express checkout option and get back the transaction ID, or receipt what ever is available. I'm a little new to iOS and any help is appreciated.
If you don't want to use any libraries or API's, Express Checkout won't work for you.
Which does make it somewhat easier, as you can just use PayPal Website Payments Standard in a UIWebView instead.
For example; just open https://www.paypal.com/cgi-bin/webscr?cmd=_xclick&business=your#email.tld&amount=1.99¤cy_code=GBP
This will start a 1.99 GBP payment to email#here.tld via PayPal, and automatically use a mobile layout.
If you subsequently want to receive transaction information; set up PayPal IPN on your account and use that to receive transaction-related events. This can be handled outside your app, and thus take away precious processing power to the server.
For an overview on getting started with PayPal IPN, have a look at https://www.paypal.com/ipn/
I would strongly suggest against trying to do transactions through paypal. If you look at the App Store Review Guidelines it states that
11.2 Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected
I'm building a utility that will hopefully keep my wife in tune with how much money we have available.
I need a simple secure way of logging into my bank account and retrieving the balance.
Something like mechanize is the only method I can think of. I'm not even sure if that would work given the properly authenticated https that banks use.
Any ideas?
Write a perl script using LWP::UserAgent. It supports HTTPS connections. The only issue might be if the site requires javascript.
Web Client Programming with Perl has a few examples to get you started if you're not too familiar with perl.
If you really want to go there, get these extensions for Firefox: Live HTTP Headers, Firebug, FireCookie, and HttpFox. Also download cURL and a scripting language that can run cURL command-line tasks (or a scripting language like PHP or Perl that has access to cURL libraries directly).
I've started down this road for some idempotent GET tasks like getting PDFs of the S&P reports (of the stocks I track) from my online brokerage, and downloading the check images for my bank account. Both tasks are repetitive and slow ways of downloading data to my computer that the financial institutions don't provide any way of making it easier.
Here's why you shouldn't: (as a shortcut I'm going to call the archetypal large bank, brokerage, or other financial institution "BloatBank")
BloatBank is not likely to make public their API for accessing this kind of information. So it can change any time and all your hard work will be for naught. Whenever they change their mechanism, you'll have to adapt.
If BloatBank finds out you've been using automatic scripting to try to access your account information, they may ban you because you've violated their terms of service.
You might screw up, and the interaction between the hodgepodge of scripts on BloatBank's server, and your scripts that access your account, might cause a Bad Thing like closing your account. Testing this kind of script is tremendously difficult because you don't have any documentation about how their online service works, and you don't have a test account you can mess with.
(a variant of the above) You think you're safe because you're issuing GET requests. But BloatBank is just a crazy bank that doesn't know anything about REST, so there are some GET requests that can mess up your account.
If someone else does use your script to maliciously sniff your online password or mess with your account, any liability coverage from BloatBank may disappear because you've opened a security hole.
Why don't you teach your wife how to login to the bank herself? Or use Quicken (or Mint, etc) and teach her how to use the auto-download feature?
Have you checked out Watir? It is fantastic for automating web-browser actions. And since it's written in Ruby, you can take the results and store them in a DB (or email them to yourself) if needed.
If you are open to AIR, I'd say build an AIR app. I have worked with mechanize and I think it's cool. AIR gives you similar features with a richer GUI (see HTMLLoader and DOM manipulation of webpage).
If I were you, I'd simply pull the page and manipulate the DOM to suit my visual needs.
Please, if you find this easy to do for your bank please post your bank's name. If I have the same one I'll be closing my account.
More to your question. The process of loading a web page inside of your code rather than in a browser can be a black art, especially if their is any javascript involved. Your best bet would probably be embedding the IE Web Browser control in your app and then simulating key strokes and mouse clicks to arrive at your balance page. Then scrape the HTML for the balance.
I could try paying for Quicken and letting it do the balance downloading. Then I'd just need to find a way to get the number out of the software automatically.
This way I'm not violating any terms of service and I'm also reducing security risk since all "hacking" goes on locally.