NPO-Accounting/perl-business-paypal-api
6
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
perl-business-paypal-api/t/OptionFields.t

96 lines
3.1 KiB
Perl
Raw Normal View History

Beginnings of OptionFields tester. I've noticed that the PII_Options field doesn't seem to properly contain the values it should. This is the beginning of a test file for what PII_Options should contain. The initial step here is to simply create one of my forms to create a test transaction, and verify that the transaction has been created.
2015-01-01 23:19:24 +00:00
# This file is part of Business:PayPal:API Module. License: Same as Perl. See its README for details.
# -*- mode: cperl -*-
use Test::More;
use strict;
use autodie to simplify code for open & $? == 0
2015-01-02 17:50:57 +00:00
use autodie qw(:all);
Move use Cwd; to top with other use statements.
2015-01-02 17:49:32 +00:00
use Cwd;
use autodie to simplify code for open & $? == 0
2015-01-02 17:50:57 +00:00
Beginnings of OptionFields tester. I've noticed that the PII_Options field doesn't seem to properly contain the values it should. This is the beginning of a test file for what PII_Options should contain. The initial step here is to simply create one of my forms to create a test transaction, and verify that the transaction has been created.
2015-01-01 23:19:24 +00:00
if ( !$ENV{WPP_TEST} || !-f $ENV{WPP_TEST} ) {
plan skip_all =>
'No WPP_TEST env var set. Please see README to run tests';
}
else {
Properly extract Options from PaymentItemInfo The Options fields found in /PaymentTransactionDetails/PaymentItemInfo/PaymentItem/Options have never been extracted in the proper way. In fact, I'd be surprised if anyone found the previous method of extraction useful at all. I discovered this bug when I needed to lookup the Options selected during payment, and found they weren't returned by the API. Specifically, the value inside the SOAP tags, which is what the API previously returned, are simply not useful: they are typically empty. The interesting data is stored in the attributes of 'name' and 'value'. Note, BTW, that each PaymentItem can have its own set of Options. This code added herein properly extracts the Options data for each PaymentItem, and places it both in the Options field for that PaymentItem, and in the array in the PII_Options "convenience" field. As can be seen in the accompanying changes to t/OptionsFields.t, the return values of the Options data is now a hash rather than a list. I believe this API-user-visible change is appropriate since a hash is ultimately the natural representation of this data, and since having the Options as an array of empty strings wasn't useful, anyway. Nevertheless, if existing user code of this API relies on Options being an array of empty strings (which I suppose could have been usefully used in scalar context to get the count of options in the record), this change theoretically creates a user-visible change in the API. I can't imagine anyone found the previous return value useful in the past anyway, so I'd be surprised if anyone relies on this mis-feature. If they did, they can simply change their code to: scalar keys ...{Options} instead of: scalar @...{Options} However, since this is technically an API change, I've updated the Changes file and the module documentation to mention it.
2015-01-02 18:09:50 +00:00
plan tests => 14;
Beginnings of OptionFields tester. I've noticed that the PII_Options field doesn't seem to properly contain the values it should. This is the beginning of a test file for what PII_Options should contain. The initial step here is to simply create one of my forms to create a test transaction, and verify that the transaction has been created.
2015-01-01 23:19:24 +00:00
}
use_ok( 'Business::PayPal::API::TransactionSearch' );
use_ok( 'Business::PayPal::API::GetTransactionDetails' );
#########################
require 't/API.pl';
my %args = do_args();
=pod
These tests verify the options work.
=cut
use autodie to simplify code for open & $? == 0
2015-01-02 17:50:57 +00:00
open(OPTIONS_PAY_HTML, ">", "options-payment.html");
Beginnings of OptionFields tester. I've noticed that the PII_Options field doesn't seem to properly contain the values it should. This is the beginning of a test file for what PII_Options should contain. The initial step here is to simply create one of my forms to create a test transaction, and verify that the transaction has been created.
2015-01-01 23:19:24 +00:00
print OPTIONS_PAY_HTML <<_OPTIONS_PAYMENT_DATA_
<html>
<body>
<form action="https://www.sandbox.paypal.com/cgi-bin/webscr" method="post" target="_top">
<input type="hidden" name="cmd" value="_xclick" />
<input type="hidden" name="business" value="$args{SellerEmail}" />
<input type="hidden" name="item_name" value="Field Options Tester" />
<input id="no_shipping" type="hidden" name="no_shipping" value="0" />
<input id="amount" type="text" name="amount" size="7" minimum="120" value="120" />
<input type="hidden" name="on1" value="firstOption" />
<input type="hidden" name="os1" value="Yes" />
<input type="hidden" name="on2" value="size"/>
<input name="os2" id="os2" value="Large"/>
<input type="image" border="0" name="submit" alt="Submit Field Tester with $120 payment">
</form></body></html>
_OPTIONS_PAYMENT_DATA_
;
use autodie to simplify code for open & $? == 0
2015-01-02 17:50:57 +00:00
close(OPTIONS_PAY_HTML);
Beginnings of OptionFields tester. I've noticed that the PII_Options field doesn't seem to properly contain the values it should. This is the beginning of a test file for what PII_Options should contain. The initial step here is to simply create one of my forms to create a test transaction, and verify that the transaction has been created.
2015-01-01 23:19:24 +00:00
Move use Cwd; to top with other use statements.
2015-01-02 17:49:32 +00:00
my $cwd = getcwd;
Beginnings of OptionFields tester. I've noticed that the PII_Options field doesn't seem to properly contain the values it should. This is the beginning of a test file for what PII_Options should contain. The initial step here is to simply create one of my forms to create a test transaction, and verify that the transaction has been created.
2015-01-01 23:19:24 +00:00
print STDERR <<"_OPTIONS_LINK_";
Please note the next series of tests will not succeeed unless there is at
least one transaction that is part of a subscription payments in your business
account.
if you haven't made one yet, you can visit:
file://$cwd/options-payment.html
and use the sandbox buyer account to make the payment.
_OPTIONS_LINK_
my $startdate = '1998-01-01T01:45:10.00Z';
my $ts = new Business::PayPal::API::TransactionSearch( %args );
my $td = new Business::PayPal::API::GetTransactionDetails( %args );
my $resp = $ts->TransactionSearch(StartDate => $startdate);
my %detail;
foreach my $record (@{$resp}) {
Indentation change & Emacs variables to enforce it The indentation style of this test file should match that of other indentation in other tests. I've also herein added Emacs variable settings to make sure Emacs users have the same style enforced.
2015-01-02 17:55:05 +00:00
%detail = $td->GetTransactionDetails(TransactionID => $record->{TransactionID});
last if $detail{PII_Name} =~ /Field\s+Options/i;
Beginnings of OptionFields tester. I've noticed that the PII_Options field doesn't seem to properly contain the values it should. This is the beginning of a test file for what PII_Options should contain. The initial step here is to simply create one of my forms to create a test transaction, and verify that the transaction has been created.
2015-01-01 23:19:24 +00:00
}
like($detail{PaymentItems}[0]{Name}, qr/Field\s+Options/i, 'Found field options test transaction');
like($detail{PII_Name}, qr/Field\s+Options/i, 'Found field options test transaction');
Properly extract Options from PaymentItemInfo The Options fields found in /PaymentTransactionDetails/PaymentItemInfo/PaymentItem/Options have never been extracted in the proper way. In fact, I'd be surprised if anyone found the previous method of extraction useful at all. I discovered this bug when I needed to lookup the Options selected during payment, and found they weren't returned by the API. Specifically, the value inside the SOAP tags, which is what the API previously returned, are simply not useful: they are typically empty. The interesting data is stored in the attributes of 'name' and 'value'. Note, BTW, that each PaymentItem can have its own set of Options. This code added herein properly extracts the Options data for each PaymentItem, and places it both in the Options field for that PaymentItem, and in the array in the PII_Options "convenience" field. As can be seen in the accompanying changes to t/OptionsFields.t, the return values of the Options data is now a hash rather than a list. I believe this API-user-visible change is appropriate since a hash is ultimately the natural representation of this data, and since having the Options as an array of empty strings wasn't useful, anyway. Nevertheless, if existing user code of this API relies on Options being an array of empty strings (which I suppose could have been usefully used in scalar context to get the count of options in the record), this change theoretically creates a user-visible change in the API. I can't imagine anyone found the previous return value useful in the past anyway, so I'd be surprised if anyone relies on this mis-feature. If they did, they can simply change their code to: scalar keys ...{Options} instead of: scalar @...{Options} However, since this is technically an API change, I've updated the Changes file and the module documentation to mention it.
2015-01-02 18:09:50 +00:00
foreach my $options ($detail{PaymentItems}[0]{Options}, $detail{PII_Options}[0]) {
ok(scalar(keys %$options) == 2, "The PaymentItems Options has 2 elements");
ok(defined $options->{firstOption}, "'firstOption' is present");
ok($options->{firstOption} eq 'Yes', "'firstOption' is selected as 'Yes'");
ok(defined $options->{size}, "'size' option is present");
ok($options->{size} eq "Large", "'size' option is selected as 'Large'");
Current Options details test: probably wrong Currently, the {PII_Options} / {PaymentItems}[0]{Options} are a list of empty strings. This is probably the incorrect behavior, which I'm about to fix. However, I'm committing this test as-is since it passes against the current code as it stands.
2015-01-02 00:06:32 +00:00
}
Properly extract Options from PaymentItemInfo The Options fields found in /PaymentTransactionDetails/PaymentItemInfo/PaymentItem/Options have never been extracted in the proper way. In fact, I'd be surprised if anyone found the previous method of extraction useful at all. I discovered this bug when I needed to lookup the Options selected during payment, and found they weren't returned by the API. Specifically, the value inside the SOAP tags, which is what the API previously returned, are simply not useful: they are typically empty. The interesting data is stored in the attributes of 'name' and 'value'. Note, BTW, that each PaymentItem can have its own set of Options. This code added herein properly extracts the Options data for each PaymentItem, and places it both in the Options field for that PaymentItem, and in the array in the PII_Options "convenience" field. As can be seen in the accompanying changes to t/OptionsFields.t, the return values of the Options data is now a hash rather than a list. I believe this API-user-visible change is appropriate since a hash is ultimately the natural representation of this data, and since having the Options as an array of empty strings wasn't useful, anyway. Nevertheless, if existing user code of this API relies on Options being an array of empty strings (which I suppose could have been usefully used in scalar context to get the count of options in the record), this change theoretically creates a user-visible change in the API. I can't imagine anyone found the previous return value useful in the past anyway, so I'd be surprised if anyone relies on this mis-feature. If they did, they can simply change their code to: scalar keys ...{Options} instead of: scalar @...{Options} However, since this is technically an API change, I've updated the Changes file and the module documentation to mention it.
2015-01-02 18:09:50 +00:00
Indentation change & Emacs variables to enforce it The indentation style of this test file should match that of other indentation in other tests. I've also herein added Emacs variable settings to make sure Emacs users have the same style enforced.
2015-01-02 17:55:05 +00:00
# Local Variables:
# Mode: CPerl
# indent-tabs-mode: nil
# cperl-indent-level: 4
# cperl-brace-offset: 0
# cperl-continued-brace-offset: 0
# cperl-label-offset: -4
# cperl-continued-statement-offset: 4
# End:
Current Options details test: probably wrong Currently, the {PII_Options} / {PaymentItems}[0]{Options} are a list of empty strings. This is probably the incorrect behavior, which I'm about to fix. However, I'm committing this test as-is since it passes against the current code as it stands.
2015-01-02 00:06:32 +00:00
Reference in a new issue Copy permalink