> Use Mock and assert_called_with:
> http://www.voidspace.org.uk/python/mock/mock.html#mock.Mock.assert_ca...
> In this case you'd set theAPI.call as your mock and check that under
> different conditions it is called correctly.
Oh, perfect -- thank you, that will help a lot!
> You don't need mo
You don't need mocks or dependency injection in this case. Just separate the
message construction code, so you can test it in isolation:
# myapp.views
from django.http import HttpResponse
from myapp.models import CurrentState
from myapp.exceptions import ApiFailureException
from third_party.api i
On 2011-06-20, at 12:52 PM, Nan wrote:
> I'm not testing the third-party service. I need to test *what I send
> to them*.
Use Mock and assert_called_with:
http://www.voidspace.org.uk/python/mock/mock.html#mock.Mock.assert_called_with
In this case you'd set theAPI.call as your mock and check
> That's what I was suggesting; that way the view becomes simple enough that
> anyone looking at it can be assured of its correctness, without a host of
> unit tests. Those tests can be applied to the functions that actually
> construct the messages.
Right, it's really those supporting functions
On Tue, Jun 21, 2011 at 7:30 AM, Nan wrote:
>
>
> > Your view function may indeed be too complex to test properly, and it
> sounds
> > like it is too tightly coupled with with the API call -- there is no way
> to
> > call the view without having it call the actual 3rd-party API as imported
> at
>
> Your view function may indeed be too complex to test properly, and it sounds
> like it is too tightly coupled with with the API call -- there is no way to
> call the view without having it call the actual 3rd-party API as imported at
> the top of the file.
I'd be a little confused as to how to
On Mon, Jun 20, 2011 at 4:25 PM, Nan wrote:
>
> Hm, I'm not worried about receiving a valid response from the third-
> party API, just about testing the value of the "msg" parameter that's
> passed into it. I need to test the msg parameter because it is in
> turn essentially a proxy for which st
Hm, I'm not worried about receiving a valid response from the third-
party API, just about testing the value of the "msg" parameter that's
passed into it. I need to test the msg parameter because it is in
turn essentially a proxy for which state was reached in my_view.
my_view is actually a grea
On Mon, Jun 20, 2011 at 3:52 PM, Nan wrote:
> I'm not testing the third-party service. I need to test *what I send
> to them*. I.e. that the output of my_view is correct. The trouble is
> that neither my_view nor the API call actually returns the output that
> I need to check.
>
> Does that mak
I'm not testing the third-party service. I need to test *what I send
to them*. I.e. that the output of my_view is correct. The trouble is
that neither my_view nor the API call actually returns the output that
I need to check.
Does that make sense?
On Jun 20, 1:59 pm, Daniel Roseman wrote:
>
On Monday, June 20, 2011 6:07:59 PM UTC+1, Nan wrote:
>
> In most situations, my app, upon receiving an HTTP request, sends data
> to a third-party API, and returns an empty HttpResponse. I need to
> test that the correct data is sent to the third-party API based on
> internal application state
In most situations, my app, upon receiving an HTTP request, sends data
to a third-party API, and returns an empty HttpResponse. I need to
test that the correct data is sent to the third-party API based on
internal application state. I'm perplexed as to how to intercept this
data in a unit test.
12 matches
Mail list logo