This repository has been archived by the owner. It is now read-only.

Balanced rev1.1 #2036

Merged
merged 12 commits into from Feb 20, 2014

Conversation

Projects
None yet
6 participants
@mahmoudimus

This starts the process of upgrading Gittip to revision 1.1 of the API and moves Gittip away from "legacy Accounts" to "Customers"

@mahmoudimus

This comment has been minimized.

Show comment
Hide comment
@mahmoudimus

mahmoudimus Feb 14, 2014

All credit here is to the good work of @matthewfl

All credit here is to the good work of @matthewfl

@mahmoudimus

This comment has been minimized.

Show comment
Hide comment
@mahmoudimus

mahmoudimus Feb 14, 2014

@gittip & @whit537 et. al, we should start the code review process.

@gittip & @whit537 et. al, we should start the code review process.

@zwn zwn added the DevX label Feb 14, 2014

@zwn

This comment has been minimized.

Show comment
Hide comment
@zwn

zwn Feb 14, 2014

Contributor

Could we drop the email while we are changing the code around it? Please see #453.

Contributor

zwn commented Feb 14, 2014

Could we drop the email while we are changing the code around it? Please see #453.

@mjallday

This comment has been minimized.

Show comment
Hide comment

This comment has been minimized.

Show comment
Hide comment
@mjallday

mjallday Feb 14, 2014

participant

participant

@mjallday

This comment has been minimized.

Show comment
Hide comment
@mjallday

This comment has been minimized.

Show comment
Hide comment
@mjallday

mjallday Feb 14, 2014

is this a bug in the balanced library?

is this a bug in the balanced library?

@mjallday

This comment has been minimized.

Show comment
Hide comment
@mjallday

mjallday Feb 14, 2014

basestring

This comment has been minimized.

Show comment
Hide comment
@matthewfl

matthewfl Feb 14, 2014

Owner

typecheck does not work with base string. It basically does type() is in ...., and str is not basestring

Owner

matthewfl replied Feb 14, 2014

typecheck does not work with base string. It basically does type() is in ...., and str is not basestring

@mjallday

This comment has been minimized.

Show comment
Hide comment
@mjallday

mjallday Feb 14, 2014

things -> funding_instuments?

things -> funding_instuments?

@mjallday

This comment has been minimized.

Show comment
Hide comment
- things = getattr(self._account, self.thing_type+'s').all()
- things = [thing for thing in things if thing.is_valid]
+ things = getattr(self._customer, self.thing_type+'s')\
+ .filter(is_valid=True).all()

This comment has been minimized.

@mjallday

mjallday Feb 14, 2014

Contributor

in 1.1 is_valid is a default filter, no need to explicitly pass it unless you want is_valid=False

@mjallday

mjallday Feb 14, 2014

Contributor

in 1.1 is_valid is a default filter, no need to explicitly pass it unless you want is_valid=False

- account = balanced.Account.find(balanced_account_uri)
- if 'merchant' not in account.roles:
+ customer = balanced.Customer.fetch(balanced_customer_href)
+ if customer.merchant_status == 'underwritten':

This comment has been minimized.

@mjallday

mjallday Feb 14, 2014

Contributor

balanced no longer has this constraint. only need to worry about merchant_status if > 100k/year. let's remove and simplify the code base

@mjallday

mjallday Feb 14, 2014

Contributor

balanced no longer has this constraint. only need to worry about merchant_status if > 100k/year. let's remove and simplify the code base

This comment has been minimized.

@chadwhitacre

chadwhitacre Feb 20, 2014

Contributor

Besides, this seems to be the opposite condition as is called for. No? Wouldn't we want merchant_status != 'underwritten?

@chadwhitacre

chadwhitacre Feb 20, 2014

Contributor

Besides, this seems to be the opposite condition as is called for. No? Wouldn't we want merchant_status != 'underwritten?

This comment has been minimized.

@matthewfl

matthewfl Feb 20, 2014

Contributor

yes this looks to backwards, it should be !=

@matthewfl

matthewfl Feb 20, 2014

Contributor

yes this looks to backwards, it should be !=

This comment has been minimized.

@chadwhitacre

chadwhitacre Feb 20, 2014

Contributor

On way or another, I've removed this in ea9d1dd.

@chadwhitacre

chadwhitacre Feb 20, 2014

Contributor

On way or another, I've removed this in ea9d1dd.

- customer = balanced.Account.find(balanced_account_uri)
- customer.debit(cents, description=username)
+ customer = balanced.Customer.fetch(balanced_customer_href)
+ customer.cards.one().debit(amount=cents, description=username)

This comment has been minimized.

@mjallday

mjallday Feb 14, 2014

Contributor

.first

@mjallday

mjallday Feb 14, 2014

Contributor

.first

+
+def setUp_balanced_resources(o):
+ o.balanced_customer_href = unicode(balanced.Customer().save().href)
+ o.card_href = unicode(balanced.Card(

This comment has been minimized.

@mjallday

mjallday Feb 14, 2014

Contributor

from __future__ import unicode_literals

@mjallday

mjallday Feb 14, 2014

Contributor

from __future__ import unicode_literals

@mjallday

This comment has been minimized.

Show comment
Hide comment
@mjallday

mjallday Feb 14, 2014

Contributor

@matthewfl looking good! I suggest we add a backwards compatibility test since this isn't testing an account uri being used with a customer.

If you create a customer and munge the stored href from /customers/CU123123 to /v1/marketplaces/MP123123/customers/CU123123 and then add a card on them and do the same for charging a card i think that will be good since that's what's going to happen for all existing customers on gittip.

Contributor

mjallday commented Feb 14, 2014

@matthewfl looking good! I suggest we add a backwards compatibility test since this isn't testing an account uri being used with a customer.

If you create a customer and munge the stored href from /customers/CU123123 to /v1/marketplaces/MP123123/customers/CU123123 and then add a card on them and do the same for charging a card i think that will be good since that's what's going to happen for all existing customers on gittip.

except balanced.exc.HTTPError as err:
- error = err.message.decode('UTF-8') # XXX UTF-8?
+ error = err.message.message.decode('UTF-8') # XXX UTF-8?

This comment has been minimized.

@chadwhitacre

chadwhitacre Feb 14, 2014

Contributor

message.message

3ec3960d0a1f1aacf42839c40e09d2a5_bigger

@chadwhitacre

chadwhitacre Feb 14, 2014

Contributor

message.message

3ec3960d0a1f1aacf42839c40e09d2a5_bigger

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Feb 14, 2014

Contributor

@mahmoudimus @matthewfl @mjallday Thanks for the PR! :-)

Contributor

chadwhitacre commented Feb 14, 2014

@mahmoudimus @matthewfl @mjallday Thanks for the PR! :-)

gittip/billing/__init__.py
@@ -35,15 +35,16 @@ def get_balanced_account(db, username, balanced_account_uri):
# XXX Balanced requires an email address
# https://github.com/balanced/balanced-api/issues/20
# quote to work around https://github.com/gittip/www.gittip.com/issues/781
+ # emails are not required for customers any more

This comment has been minimized.

@chadwhitacre

chadwhitacre Feb 14, 2014

Contributor

+1 to dropping email if we can here, as @zwn suggests at #2036 (comment). Our ticket for this: #453.

@chadwhitacre

chadwhitacre Feb 14, 2014

Contributor

+1 to dropping email if we can here, as @zwn suggests at #2036 (comment). Our ticket for this: #453.

@matthewfl

This comment has been minimized.

Show comment
Hide comment
@matthewfl

matthewfl Feb 14, 2014

Contributor

I will drop the email requirement as @zwn pointed out. I plan to add a few more tests for the payday scripts as I noticed that there were a number of lines that were not being covered.

Contributor

matthewfl commented Feb 14, 2014

I will drop the email requirement as @zwn pointed out. I plan to add a few more tests for the payday scripts as I noticed that there were a number of lines that were not being covered.

@matthewfl

This comment has been minimized.

Show comment
Hide comment
@matthewfl

matthewfl Feb 15, 2014

Contributor

Update: I have removed the email constraint, and have tested adding cards and bank accounts and they both appear to work. Additionally, I added a Last four of ssn field on the bank account. I am not sure what the communities opinion is with respect to having this information, however if a user is having a hard time confirming their identity, then including the last four digits of their ssn often greatly improves their chances of a match.

As for tests, there is a test for balanced which checks that old urls can be used. Balanced has a fix for this going public shortly, but in the mean time this test is expected to fail.

Contributor

matthewfl commented Feb 15, 2014

Update: I have removed the email constraint, and have tested adding cards and bank accounts and they both appear to work. Additionally, I added a Last four of ssn field on the bank account. I am not sure what the communities opinion is with respect to having this information, however if a user is having a hard time confirming their identity, then including the last four digits of their ssn often greatly improves their chances of a match.

As for tests, there is a test for balanced which checks that old urls can be used. Balanced has a fix for this going public shortly, but in the mean time this test is expected to fail.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Feb 15, 2014

Contributor

Additionally, I added a Last four of ssn field on the bank account.

Currently we direct the user to Balanced if the identity verification fails with basic info. I would love it if we could keep the user on our site for this escalation, but I'd rather not present them with an SSN field unless verification fails without it.

Contributor

chadwhitacre commented Feb 15, 2014

Additionally, I added a Last four of ssn field on the bank account.

Currently we direct the user to Balanced if the identity verification fails with basic info. I would love it if we could keep the user on our site for this escalation, but I'd rather not present them with an SSN field unless verification fails without it.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Feb 15, 2014

Contributor

@matthewfl Can you look into why Travis is failing?

Contributor

chadwhitacre commented Feb 15, 2014

@matthewfl Can you look into why Travis is failing?

@matthewfl

This comment has been minimized.

Show comment
Hide comment
@matthewfl

matthewfl Feb 15, 2014

Contributor

@whit537 Balanced is removing the support for the redirect to our site. With customers, instead of throwing an error when the match fails, the merchant status on the customer will simply report there is not a match. This means the site can continue to resubmit information.

One of the failures is the test that I referenced above

Contributor

matthewfl commented Feb 15, 2014

@whit537 Balanced is removing the support for the redirect to our site. With customers, instead of throwing an error when the match fails, the merchant status on the customer will simply report there is not a match. This means the site can continue to resubmit information.

One of the failures is the test that I referenced above

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Feb 15, 2014

Contributor

Balanced is removing the support for the redirect to our site.

Ah, got it, okay. I'll take a look at the UX for this ...

Contributor

chadwhitacre commented Feb 15, 2014

Balanced is removing the support for the redirect to our site.

Ah, got it, okay. I'll take a look at the UX for this ...

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Feb 15, 2014

Contributor

One of the failures is the test that I referenced above

Got it now, sorry.

Contributor

chadwhitacre commented Feb 15, 2014

One of the failures is the test that I referenced above

Got it now, sorry.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Feb 15, 2014

Contributor

I've run the test suite locally, and I get the same result as Travis:

=============================================== FAILURES ===============================================
__________________________ TestBalancedCard.test_balanced_works_with_old_urls __________________________
Traceback (most recent call last):
  File "/Users/whit537/personal/gittip/www.gittip.com/tests/test_billing.py", line 120, in test_balanced_works_with_old_urls
    card = billing.BalancedCard(url_user)
  File "/Users/whit537/personal/gittip/www.gittip.com/gittip/billing/__init__.py", line 233, in __init__
    things = getattr(self._customer, self.thing_type+'s')\
  File "/Users/whit537/personal/gittip/www.gittip.com/env/lib/python2.7/site-packages/balanced/resources.py", line 193, in __getattr__
    self.__class__.__name__, item
AttributeError: 'Customer' has no attribute 'cards'
================================ 1 failed, 335 passed in 170.08 seconds ================================
make: *** [test] Error 1
$

However, the test suite runs 10x slower than on master. Most of the slowdown seems to be in test_payday.py. What's the cause of the slowdown, I wonder?

Contributor

chadwhitacre commented Feb 15, 2014

I've run the test suite locally, and I get the same result as Travis:

=============================================== FAILURES ===============================================
__________________________ TestBalancedCard.test_balanced_works_with_old_urls __________________________
Traceback (most recent call last):
  File "/Users/whit537/personal/gittip/www.gittip.com/tests/test_billing.py", line 120, in test_balanced_works_with_old_urls
    card = billing.BalancedCard(url_user)
  File "/Users/whit537/personal/gittip/www.gittip.com/gittip/billing/__init__.py", line 233, in __init__
    things = getattr(self._customer, self.thing_type+'s')\
  File "/Users/whit537/personal/gittip/www.gittip.com/env/lib/python2.7/site-packages/balanced/resources.py", line 193, in __getattr__
    self.__class__.__name__, item
AttributeError: 'Customer' has no attribute 'cards'
================================ 1 failed, 335 passed in 170.08 seconds ================================
make: *** [test] Error 1
$

However, the test suite runs 10x slower than on master. Most of the slowdown seems to be in test_payday.py. What's the cause of the slowdown, I wonder?

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Feb 15, 2014

Contributor

Sorry, there is no test_payday.py. Slow tests start in test_billing.py. I have trouble sticking around long enough to see what else is slow. :-)

Contributor

chadwhitacre commented Feb 15, 2014

Sorry, there is no test_payday.py. Slow tests start in test_billing.py. I have trouble sticking around long enough to see what else is slow. :-)

@matthewfl

This comment has been minimized.

Show comment
Hide comment
@matthewfl

matthewfl Feb 15, 2014

Contributor

Sorry about the slow down, I guess I never noticed the major slow down. As for the reason, I decided to make the test actually use the balanced api when testing the payments system. I felt that actually testing against the api ensure that the actions are going to happen as we expect instead of how we mocked.

To fix this I am thinking of two possibilities, first we could remock all of the balanced api and stop making api requests during the test. Alternately, we could split the tests into those that make api requests (slow) and those that don't, then you would only need to run the slower tests when you were specifically working on that specific subsystem. We could then travis run both sets of tests. This second option adds a little bit of complexity by splitting the tests into two different parts, however it start a framework for which you would be able to build other network based tests.

Contributor

matthewfl commented Feb 15, 2014

Sorry about the slow down, I guess I never noticed the major slow down. As for the reason, I decided to make the test actually use the balanced api when testing the payments system. I felt that actually testing against the api ensure that the actions are going to happen as we expect instead of how we mocked.

To fix this I am thinking of two possibilities, first we could remock all of the balanced api and stop making api requests during the test. Alternately, we could split the tests into those that make api requests (slow) and those that don't, then you would only need to run the slower tests when you were specifically working on that specific subsystem. We could then travis run both sets of tests. This second option adds a little bit of complexity by splitting the tests into two different parts, however it start a framework for which you would be able to build other network based tests.

@mjallday

This comment has been minimized.

Show comment
Hide comment
@mjallday

mjallday Feb 16, 2014

Contributor

@matthewfl there's a couple of python libraries similar to ruby's VCR which would fit the build here. Betamax and VCRpy both can make the actual http call and record the response for later testing. Best of both worlds potentially?

On Feb 15, 2014, at 15:38, Matthew Francis-Landau notifications@github.com wrote:

Sorry about the slow down, I guess I never the major slow down. As for the reason, I decided to make the test actually use the balanced api when testing the payments system. I felt that actually testing against the api ensure that the actions are going to happen as we expect instead of how we mocked.

To fix this I am thinking of two possibilities, first we could remock all of the balanced api and stop making api requests during the test. Alternately, we could split the tests into those that make api requests (slow) and those that don't, then you would only need to run the slower tests when you were specifically working on that specific subsystem. We could then travis run both sets of tests. This second option adds a little bit of complexity by splitting the tests into two different parts, however it start a framework for which you would be able to build other network based tests.


Reply to this email directly or view it on GitHub.

Contributor

mjallday commented Feb 16, 2014

@matthewfl there's a couple of python libraries similar to ruby's VCR which would fit the build here. Betamax and VCRpy both can make the actual http call and record the response for later testing. Best of both worlds potentially?

On Feb 15, 2014, at 15:38, Matthew Francis-Landau notifications@github.com wrote:

Sorry about the slow down, I guess I never the major slow down. As for the reason, I decided to make the test actually use the balanced api when testing the payments system. I felt that actually testing against the api ensure that the actions are going to happen as we expect instead of how we mocked.

To fix this I am thinking of two possibilities, first we could remock all of the balanced api and stop making api requests during the test. Alternately, we could split the tests into those that make api requests (slow) and those that don't, then you would only need to run the slower tests when you were specifically working on that specific subsystem. We could then travis run both sets of tests. This second option adds a little bit of complexity by splitting the tests into two different parts, however it start a framework for which you would be able to build other network based tests.


Reply to this email directly or view it on GitHub.

@matthewfl

This comment has been minimized.

Show comment
Hide comment
@matthewfl

matthewfl Feb 18, 2014

Contributor
=================== test session starts ===================
platform linux2 -- Python 2.7.6 -- pytest-2.3.4
plugins: cache
collected 336 items 

tests/test_anonymous_json.py .....
tests/test_associate.py .....
tests/test_billing.py ...............
tests/test_billing_payday.py ...............................................
tests/test_bitcoin_json.py ...
tests/test_charts_json.py ........
tests/test_communities.py ......
tests/test_communities_json.py ......
tests/test_elsewhere.py ......
tests/test_elsewhere_bitbucket.py ..
tests/test_elsewhere_bountysource.py .
tests/test_elsewhere_github.py ..
tests/test_elsewhere_openstreetmap.py ..
tests/test_elsewhere_twitter.py ..
tests/test_fake_data.py .
tests/test_goal_json.py ..........
tests/test_hooks.py ....
tests/test_is_suspicious.py ....
tests/test_lookup_json.py ...
tests/test_membername_json.py .............
tests/test_pages.py .....................
tests/test_participant.py .......................................................................
tests/test_public_json.py ............
tests/test_record_an_exchange.py ............
tests/test_statement_json.py ....
tests/test_stats.py ..........
tests/test_take.py ........
tests/test_teams.py ............
tests/test_tip_json.py ..
tests/test_tips_json.py .......
tests/test_user.py ..................
tests/test_username_json.py .......
tests/test_utils.py .......
===================== 336 passed in 41.96 seconds =====================

@whit537 using @mjallday suggestion, I was able to reduce the time it takes the tests to run. For me, this is even a little faster than running the tests on the master branch.

Contributor

matthewfl commented Feb 18, 2014

=================== test session starts ===================
platform linux2 -- Python 2.7.6 -- pytest-2.3.4
plugins: cache
collected 336 items 

tests/test_anonymous_json.py .....
tests/test_associate.py .....
tests/test_billing.py ...............
tests/test_billing_payday.py ...............................................
tests/test_bitcoin_json.py ...
tests/test_charts_json.py ........
tests/test_communities.py ......
tests/test_communities_json.py ......
tests/test_elsewhere.py ......
tests/test_elsewhere_bitbucket.py ..
tests/test_elsewhere_bountysource.py .
tests/test_elsewhere_github.py ..
tests/test_elsewhere_openstreetmap.py ..
tests/test_elsewhere_twitter.py ..
tests/test_fake_data.py .
tests/test_goal_json.py ..........
tests/test_hooks.py ....
tests/test_is_suspicious.py ....
tests/test_lookup_json.py ...
tests/test_membername_json.py .............
tests/test_pages.py .....................
tests/test_participant.py .......................................................................
tests/test_public_json.py ............
tests/test_record_an_exchange.py ............
tests/test_statement_json.py ....
tests/test_stats.py ..........
tests/test_take.py ........
tests/test_teams.py ............
tests/test_tip_json.py ..
tests/test_tips_json.py .......
tests/test_user.py ..................
tests/test_username_json.py .......
tests/test_utils.py .......
===================== 336 passed in 41.96 seconds =====================

@whit537 using @mjallday suggestion, I was able to reduce the time it takes the tests to run. For me, this is even a little faster than running the tests on the master branch.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Feb 19, 2014

Contributor

That's awesome @matthewfl, thank you.

@seanlinsley Weren't you talking about VCR in some other context? Was that you?

Contributor

chadwhitacre commented Feb 19, 2014

That's awesome @matthewfl, thank you.

@seanlinsley Weren't you talking about VCR in some other context? Was that you?

@seanlinsley

This comment has been minimized.

Show comment
Hide comment
@seanlinsley

seanlinsley Feb 19, 2014

Contributor

I've used the Ruby version of VCR before, but I don't think I've mentioned it here 🐙

Contributor

seanlinsley commented Feb 19, 2014

I've used the Ruby version of VCR before, but I don't think I've mentioned it here 🐙

@kyungmin kyungmin referenced this pull request Feb 20, 2014

Closed

Coinbase #2052

@chadwhitacre chadwhitacre referenced this pull request Feb 20, 2014

Closed

Coinbase #2053

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Feb 20, 2014

Contributor

VCR is way cool. :-)

$ rm -rf tests/fixtures/*
$ make test
... 336 passed in 320.69 seconds
$ make test
... 336 passed in 18.37 seconds
Contributor

chadwhitacre commented Feb 20, 2014

VCR is way cool. :-)

$ rm -rf tests/fixtures/*
$ make test
... 336 passed in 320.69 seconds
$ make test
... 336 passed in 18.37 seconds

chadwhitacre added a commit that referenced this pull request Feb 20, 2014

@chadwhitacre chadwhitacre merged commit 401dc6b into gratipay:master Feb 20, 2014

1 check passed

default The Travis CI build passed
Details

chadwhitacre added a commit that referenced this pull request Feb 20, 2014

Take VCR cassettes out of repo
In #2036 we sprouted the ability to record HTTP sessions during testing
and then reuse the result of those sessions in subsequent tests. This is
done via the VCR library (a port from Ruby). Storing the cache in the
repo doesn't seem quite right to me, so in this PR I'm proposing we take
it out. The implication is that the first run of the test suite will
take a loooong time to prime the cache. Subsequent runs should be an
order of magnitude faster (back down near where we were before).

chadwhitacre added a commit that referenced this pull request Feb 20, 2014

keep database name in sync with Balanced API
In #2036 we upgraded to the 1.1 version of the Balanced API. This commit
propagates nomenclature changes down into the database, for a consistent
developer experience.

chadwhitacre added a commit that referenced this pull request Feb 20, 2014

Move VCR setup further up, onto Harness class
In #2036 we started using VCR to freeze HTTP API calls into test
fixtures. This is great! Let's do more of that! This commit moves the
VCR configuration upstream from where it began (in test_billing.py) into
the gittip.testing.Harness class. Now all tests can make expensive HTTP
API calls with impunity. In fact, this knocks out a XXX comment, because
we had one API call elsewhere in the test suite. VCR transparently took
care of it for us! I was quite pleasantly surprised to find
TestPages.yml. Yay VCR! :-)

My first motivation in doing this, however, was to be able to write a
test for regression I'm seeing with payday (#2057). Onward!

chadwhitacre added a commit that referenced this pull request Feb 20, 2014

Here's two failing tests for some payday bugs
These address regressions introduced by #2036.
+ mp = balanced.Marketplace.my_marketplace
+ if not mp:
+ mp = balanced.Marketplace().save()
+ o.balanced_marketplace = mp

This comment has been minimized.

@seanlinsley

seanlinsley Mar 4, 2014

Contributor

Coming from: #2112 (comment)

Is it really the best idea to build a new API key & secret every time you run the test suite? It seems like that produces unnecessary churn in the git history.

@seanlinsley

seanlinsley Mar 4, 2014

Contributor

Coming from: #2112 (comment)

Is it really the best idea to build a new API key & secret every time you run the test suite? It seems like that produces unnecessary churn in the git history.

This comment has been minimized.

@mjallday

mjallday Mar 5, 2014

Contributor

At Balanced we do this on every test run. It's an easy way to ensure that we've got a clean slate before we begin and hitting the API means you're guaranteed that whatever the server is doing is compatible with your code. Generally I'd recommend doing that if you're interacting with the Balanced API, the fact that gittip is checking in fixture data makes the commits really large whenever it changes however.

@mjallday

mjallday Mar 5, 2014

Contributor

At Balanced we do this on every test run. It's an easy way to ensure that we've got a clean slate before we begin and hitting the API means you're guaranteed that whatever the server is doing is compatible with your code. Generally I'd recommend doing that if you're interacting with the Balanced API, the fact that gittip is checking in fixture data makes the commits really large whenever it changes however.

This comment has been minimized.

@seanlinsley

seanlinsley Mar 5, 2014

Contributor

As of cde5468 / 6319794 we're ignoring VCR cassettes on Travis, ensuring our CI does real API requests. I suppose we need a system that will create a blank slate on Travis, but will use a predefined key in development.

@seanlinsley

seanlinsley Mar 5, 2014

Contributor

As of cde5468 / 6319794 we're ignoring VCR cassettes on Travis, ensuring our CI does real API requests. I suppose we need a system that will create a blank slate on Travis, but will use a predefined key in development.

chadwhitacre added a commit that referenced this pull request Apr 2, 2014

Take out configure_payments hack
With the upgrade to the balanced library in #2036 we no longer need this
workaround for balanced/balanced-python#5.
Removing at this point because I'm ripping out all of our direct
os.environ usage and this applies.

chadwhitacre added a commit that referenced this pull request Apr 3, 2014

Take out configure_payments hack
With the upgrade to the balanced library in #2036 we no longer need this
workaround for balanced/balanced-python#5.
Removing at this point because I'm ripping out all of our direct
os.environ usage and this applies.

@chadwhitacre chadwhitacre referenced this pull request in gratipay/inside.gratipay.com Apr 3, 2014

Closed

Create policy doc for in what ways we can transact with vendors #15

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.