We need to make it easy for developers outside of the fundraising tech team to contribute to this extension.
In a nutshell, I want to come out of the other end of the hackathon, with an entirely new layer of dummy 3rd party accounts (one for every payment gateway) that will allow developers to be able to work on and test DonationInterface code locally on their own machines, with minimal setup and no actual need to communicate with 3rd parties. I'd also like to think of clever ways to make appropriate levels of developer-friendly information appear when you are using those dummy accounts, and just generally make it more pleasant to be working on that stuff in the first place.
For contrast: Right now, you can't even install the extension and get it to do anything but emit a bunch of errors unless you have some appropriate credentials. Most people have to give up right there. In fact, nobody at all has gotten any farther than that in years unless I hired them specifically to work on that code, and I usually have to (securely, which is a whole other mess) send them an abridged version of my LocalSettings before they can even get an initial form to load.
We want to work with people who have never tried to install DonationInterface before, so we can see where the process is falling down for normal people after we implement each of the steps outlined (shortly) in subtasks.
Installing the Fundraising tech development environment
Once you have provisioned a box, you should be able to read the built-in documentation which will lead you further.
Iterative list of Goals
...in approximate chronological order. However far down this list we get, would be grand.
Installing DonationInterface with no extra settings or 3rd party credentials, should not blow up your entire MediaWiki instance.
- T99954: In the event that credentials for a gateway are not supplied, that gateway should go in to local development mode.
- It should be inescapably obvious to the user, whenever they are in local dev mode… but not in such an extreme way that we couldn’t use this technique to finally allow selenium tests to be possible.
- In local dev mode, there will be no attempts to actually contact third parties. Ideally, this would be rendered impossible within all gateways in local dev mode.
- Short-circuit all FormChooser safety checks, for any gateway in local dev mode.
- All 3rd party responses and workflows will be faked when we are in local dev mode.
- When a gateway takes you to a piece of the workflow hosted by a 3rd party, local dev mode will allow the user to supply the values for expected parameters that they would like to be pretending to receive from the 3rd party.
- For all gateways, if the user is typically sent away to a third party and expected to return, it should always be possible in local dev mode to get 100% of the way to the Thank You or Error page by very thoroughly faking the external bits, internally.
- T99955 - Write browser tests (Selenium and/or Cucumber) that work in local dev mode.
- T99957 - Write MW-Vagrant puppet to allow us to spin up dev, staging, and testing instances, and deploy sandbox servers on WMF-labs.
- We should swap the queue out for Redis during normal development, cos it's already provisioned and will save precious VPS resources. Currently we are coupled to ActiveMQ, but see completed preparatory work in the code, which wraps queue access in an abstract shim, T92916.