Python SDK interface design about stripe-python HOT 7 CLOSED

👎

That is not very pythonic.

Why do you need to stub the API requests when testing the integration at all? That is what test keys are for.

from stripe-python.

@danielchatfield might be, I can't say I'm an expert in what software is pythonic/non-pythonic. All I'm concerned of is the fact that I don't want to hit HTTP during my tests and I don't want to return mocks of the mocks while trying to avoid that.

This is more like an open discussion and I would be happy to see a solution that doesn't involve changing existing interface and answers my questions.
Thanks.

from stripe-python.

Could you show an example of the sort of tests you are talking about
(trying to get an idea of what you are trying to test).

On Thursday, 22 May 2014, Stas Sușcov [email protected] wrote:

@danielchatfield https://github.com/danielchatfield might be, I can't
say I'm an expert in what software is pythonic/non-pythonic. All I'm
concerned of is the fact that I don't want to hit HTTP during my tests and
I don't want to return mocks of the mocks while trying to avoid that.

This is more like an open discussion and I would be happy to see a
solution that doesn't involve changing existing interface and answers my
questions.
Thanks.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/79#issuecomment-43877866
.

For contact info visit: www.danielchatfield.com

from stripe-python.

One thing I've been considering is to support more dependency injection in the API. In that case, you would provide your own implementation of the HTTPClient that stubs out any requests. I think this would also solve issues like #38 and #23.

For the time being, can you just stub out stripe.http_client.new_default_http_client to return your own stubbed client?

from stripe-python.

👍

APIRequestor supports the passing of a client parameter but this isn't
used outside of the unit tests.

ᐧ

On 22 May 2014 16:13, Andrew Metcalf [email protected] wrote:

One thing I've been considering is to support more dependency injection in
the API. In that case, you would provide your own implementation of the
HTTPClient that stubs out any requests. I think this would also solve
issues like #38 #38 and #23#23
.

For the time being, can you just stub out
stripe.http_client.new_default_http_client to return your own stubbed
client?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/79#issuecomment-43901537
.

For contact info visit: www.danielchatfield.com

from stripe-python.

Thanks @metcalf.

Dependency injection sounds good if you care what happens in between the call and the response. I don't think most do.
I'm looking for a solution where I can mock with an expectation the Customer.cards.create method.
Right now I need to mock the customer, its cards and finally the create method.

Normally I would just mock Customer.create_card method.
Does it make sense?

from stripe-python.

I understand what you're getting at. I think the right answer is to either mock all of those things or stub out APIRequestor altogether. I think the customer.cards namespacing is clearer for most use cases and is consistent with our other Python bindings. If it's just a question of an additional mocking step, I think this is WONTFIX.

from stripe-python.