docs/testing.md
The whole test suite:
$ bin/rspec
A single file:
$ bin/rspec spec/requests/dashboard_spec.rb
A specific test:
$ bin/rspec spec/requests/dashboard_spec.rb:75
make local in a separate shell to spin up required services (e.g. db) through Docker.RAILS_ENV=test bin/rails db:setup to set up the test database.RAILS_ENV=test bin/rails js:export to update autogenerated JavaScript files for the test environment.We use capybara with selenium (webdriver) for our integration specs.
js-* one.click_on "Text" or, if that doesn't work, find_and_click "selector", text: "Text", are preferred.fill_in "locator", with: "value" or find("locator").fill_in(with: "value") over x.native.send_keys("...").For integration specs, we use Chrome and chromedriver.
For Linux:
$ wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo apt-key add -
$ sudo sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list'
$ sudo sudo apt-get update
$ sudo apt-get install google-chrome-stable
For macOS, you need to install XQuartz to run the request specs.
$ brew install XQuartz
https://github.com/gumroad/web/issues/8410#issuecomment-318496067
There are some basic tips you can use to prevent flaky specs in Capybara
expect(page).to have_selector("selector") as much as possible. This is a smart method in Capybara that handles several situations. Do not use find if you can help it. have_selector is your friend!sleep, it is hacky and will lead to flakiness.wait_for_ajax if you need to make sure all ajax requests have finished.for i in {1..10}; do
echo "Run number $i\n-"
bin/rspec spec/requests/product_creation_spec.rb:28
done
If the spec is new or modified by your PR: It likely broke because of your changes. Try to fix it. Ask for help from the reviewer when you assign it for review if you can't fix it.
If you are sure the failing specs are unrelated to your PR: It could be a flaky spec. Confirm the spec passes multiple times locally but not on CI. Let the reviewer know when you assign it for review (example).
Try running this again:
RAILS_ENV=test bin/rails js:export
The bin/dev script automatically generates JS constants for the development domain, so without this command the tests will try to navigate to that instead of the test domain.
If you're running an integration spec and it times out with this error:
Selenium::WebDriver::Error::WebDriverError:
unable to obtain stable chromedriver connection in 60 seconds (127.0.0.1:7055)
If you're running an integration spec and it times out with this error:
<Rack::Timeout::RequestTimeoutError: Request ran for longer than 60000ms >
You can disable Rack timeout locally. Create a file .env.test.local with the following contents:
DISABLE_RACK_TIMEOUT="1"
For the new env variables to take effect, you might need to run bin/spring stop before running the tests again.
You can preview emails locally at /rails/mailers
Use domains-staging.gumroad.com instead of domains.gumroad.com in the DNS record.
Add a host entry in /etc/hosts
127.0.0.1 sample-custom-domain.example.com
Configure sample-custom-domain.example.com as a custom domain in gumroad.dev/settings/advanced
Remove Rails.env.development? || part from this line
Restart the server and navigate to http://sample-custom-domain.example.com:3000
That will load the profile page of the creator through the custom domain.
When testing purchases, only use the test credit card numbers listed in Stripe's documentation.
Examples:
4242 4242 4242 42424000 0000 0000 0077We use Braintree as a gateway for PayPal as of writing this wiki.
[email protected] (any email)password (any string will work)Used for Payouts. No sandbox sales/transactions will show up here as Braintree does not integrate with the PayPal sandbox.
[email protected]We currently rely on IPN messages for:
Used as a gateway for PayPal transactions. Only for transaction creation, user vaulting and refunds
Ask someone who has payments credentials for an account for Braintree in either sandbox or production.
The overlay and embed widgets both rely on iFrames and are best tested by running a host page on a separate web server. Sinatra is a great tool to get up and running quickly with a web page running on its own server.
Both widgets now detect the Rails application environment automatically -- simply include the script from whichever environment you wish to investigate, e.g. <script src="https://gumroad.dev/js/gumroad.js"/>. The code snippets on the /widgets page also reflect the current environment.
There is a simple web app in our repository called web-overlay-test. Once you check it out, follow these instructions to test the overlay and/or embed.
index.html to include the permalinks of your productsruby web.rbsudo gem install sinatraWe use QA Wolf for visual testing. QA Wolf is enabled by default on main branch and is not enabled by default on feature branches.
# Run this in a rails console
sub = Subscription.last.charge!
sub.charge!
Note: If creating multiple subscription purchases in a short time, this method may run afoul of purchase model validations (e.g., Purchase#not_double_charged). In these cases you may comment out such validations for testing purposes.
Add a payment method to your browser (Eg: for Chrome, add the Stripe 4242 4242 4242 4242 card in chrome://settings/payments)
discover.gumroad.dev, creator.gumroad.dev, discover.staging.gumroad.com are already added.Set up wallet on Android phone and access website from mobile Chrome browser.
After 3 failed purchase attempts from the same buyer, your browser GUID gets banned. You'll see the following message:
To overcome this:
# Run this in a rails console
purchase = Purchase.last
BlockedObject.browser_guid.active.find_by(purchase.browser_guid).destroy
purchase.destroy
Making another purchase with a different buyer email should work now.