-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CyberSource: Add support for issuer additionalData gateway-specific field #3296
CyberSource: Add support for issuer additionalData gateway-specific field #3296
Conversation
192e4dc
to
a46b52d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fine as far as I can tell. I added a couple of notes about ways the code might be further improved.
assert_success response | ||
assert response.test? | ||
assert_successful_response(response) | ||
assert !response.authorization.blank? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider changing this to assert_not
instead of assert !
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's actually not code that I added, so I'll leave it alone for now since assert !
is used consistently (15 times) throughout the tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I'm slightly bewildered as to why GitHub shows this with a green highlight, but it is indeed in master here: https://github.com/activemerchant/active_merchant/blob/master/test/remote/gateways/remote_cyber_source_test.rb#L107).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this something worth refactoring for readability?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do like assert_not
better in general too, but I think consistency within the same test case is more important, so I would stick with assert !
if that's what's used throughout the rest of the nearby code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, agreed that consistency is most important! My question was whether this is something that would be worth changing throughout this test file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, gotcha. Doesn't hurt either way in my opinion, but probably in this case it is a matter of deciding how far to go for the immediate ticket vs. leaving otherwise unrelated changes to a different refactor.
I know I always see more I want to do, but often have to determine what is necessary for the task at hand and constrain myself to that. 🙂
@@ -590,4 +604,11 @@ def test_verify_credentials | |||
assert !gateway.verify_credentials | |||
end | |||
|
|||
private | |||
|
|||
def assert_successful_response(response) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like this method wasn't extracted out from all of the other tests, leading to some tests still including all three lines (e.g., test_successful_authorization_with_elo
) and others using this new private method. This seems like a good thing to make consistent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, there were a lot of them. I refactored them all to DRY things out.
a46b52d
to
d3dbff2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! 🚢
assert_success response | ||
assert response.test? | ||
assert_successful_response(response) | ||
assert !response.authorization.blank? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do like assert_not
better in general too, but I think consistency within the same test case is more important, so I would stick with assert !
if that's what's used throughout the rest of the nearby code.
…ield Added support for the issuer additionalData CyberSource-specific field. The CyberSource XML schema has also been updated. Per the gateway's instructions, we are now using version 1.156 in the test environment, and version 1.155 in production. CE-56 Unit tests: 4195 tests, 70144 assertions, 0 failures, 0 errors, 0 pendings, 2 omissions, 0 notifications 100% passed test/remote/gateways/remote_cyber_source_test.rb contains 5 pre-existing, unrelated test failures: - test_successful_3ds_validate_authorize_request - test_successful_3ds_validate_purchase_request - test_successful_pinless_debit_card_puchase - test_successful_tax_calculation - test_successful_validate_pinless_debit_card 59 tests, 260 assertions, 5 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
d3dbff2
to
7e5a1c9
Compare
Added support for the issuer additionalData CyberSource-specific field. The CyberSource XML schema has also been updated. Per the gateway's instructions, we are now using version 1.156 in the test environment, and version 1.155 in production.