Mike wrote:
On Thu, Jun 4, 2009 at 4:40 AM, Terry Reedy <tjre...@udel.edu
<mailto:tjre...@udel.edu>> wrote:
Mike wrote:
Hello,
I'm writing an application that needs to fetch a json file from
a webserver. I'm writing the tests and have a question:
if I have the following methods:
def test_headers(self):
headers = libary.get_data(data)
check header status
With no json experience specifically....
Checking I/O is nasty since the test running correctly depends on
external resources running correctly and not just your program. I
would separate I/O tests from 'process the data' checks and do the
latter with canned data. If the canned data built into the test is
the same as that on the test server, then testing the fetch is an
equality test.
Thanks, I think I need to separate the tests.
The way JSON works is: Open a url with a request <- this returns a file
like object, the JSON libary reads the file like object and returns a
list of dictionary objects.
So first I want to make sure when I do the request I get a 200 OK
response, second I want to make sure the JSON object matches my
predefined object for it (to ensure no API changes).
I think I'll have an external test, which will do two calls (unless I
can use the result of the response check test). And if this test passes
I will then run my mock test which tests for functionality (and can be
run offline). If the first fails then its an indication that the api may
have changed and I need to change my mocks.
Is this a good testing method/ approach?
Let us back up a bit. The purpose of a unit test is to test a unit of
functionality that you have written code for -- usually with the
assumption, possibly false, that the interpreter and libraries are
bug-free with respect to your usage. Without knowing what you have
written, and therefore, what you should be testing, I am reluctant to
say more than that you seem to be on the right track. But some of what
you say above seems to be describing higher level integration testing,
in particular, interfacing with a changing environment.
One thing I will say: once you have tests passing, you can change either
your code or the system-code-data it works with, but should not do both
(lest you drive yourself mad). The point of mock objects is to have a
stable environment in which to work. So I would try to separate
'testing my code (which I control)' from 'testing for undisclosed
changes in external servers (that I do not control)'.
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
