Testing Your Gateway

There are two types of tests for each gateway.

The first are the normal unit tests, which test the normal functionality of the gateway, and use Mocha to stub out any communications with live servers.

The second type are the remote unit tests, which require real test accounts and communicate with the test servers of the payments gateway. These are critical to having confidence in the implementation of the gateway.

When the gateway skeleton is generated, an entry is made in test/fixtures.yml for remote test credentials. These sample credentials should be renamed to match the gateway’s naming conventions for credentials and populated with appropriate values. If the gateway offers public testing credentials, these should be added and committed. Otherwise, update the public fixtures file with the appropriate credential names and placeholder text. You may then create private fixtures that will not be committed by creating another fixtures file at ~/.active_merchant/fixtures.yml and inserting the credentials there.

At a minimum, both unit and remote tests should exercise successful and failed transaction types and transcript scrubbing. The generated test files include unit and remote test stubs for these tests. The remote tests will implicitly handle testing that the setup for gateway authentication is operational; they also contain a stub for a failed login scenario. Features unique to the gateway such as special transaction amounts or card numbers for certain outcomes should be appropriately named in the test setup, and any special options implemented should also be tested.

It is useful to work on remote tests first, both because they're less complex (no mocking/stubbing) and because you can capture the request/response easily which can then be copied to the unit tests using the DEBUG_ACTIVE_MERCHANT environment variable (see example below).

A note on testing transcript scrubbing: It’s better to scrub overzealously than to risk leaking cardholder data. The tests as stubbed offer a pattern to confirm that nothing that could be sensitive data appears anywhere in the transcript; this pattern should be maintained.

Example gateway tests

Ixopay

• Unit tests
• Remote tests

To run tests:

$ bundle install
$ bundle exec rake test:local   #Runs `test:units` and `rubocop`. All these tests should pass.
$ bundle exec rake test:remote  #Will not pass without updating test/fixtures.yml with credentials

To run a test suite individually:

$ bundle exec rake test:units TEST=test/unit/gateways/nab_transact_test.rb
$ bundle exec rake test:remote TEST=test/remote/gateways/remote_nab_transact_test.rb

To run a specific test case use the -n flag:

$ ruby -Itest test/remote/gateways/remote_nab_transact_test.rb -n test_successful_purchase

To capture the actual HTTP request sent and response received, use the DEBUG_ACTIVE_MERCHANT environment variable.

$ DEBUG_ACTIVE_MERCHANT=true ruby -Itest test/remote/gateways/remote_nab_transact_test.rb -n test_successful_purchase
<- "POST /test/xmlapi/payment...
<- "<?xml version=\"1.0\" ..."
-> "HTTP/1.1 200 OK\r\n"
-> "Content-Type: text/xml;charset=ISO-8859-1\r\n"
-> "Content-Length: 954\r\n"
...