unittest - what is the best way to reuse test data?
42flicks at gmail.com
Wed Jun 3 20:03:39 EDT 2009
On Thu, Jun 4, 2009 at 11:22 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> Mike wrote:
>> On Thu, Jun 4, 2009 at 4:40 AM, Terry Reedy <tjreedy at udel.edu <mailto:
>> tjreedy at udel.edu>> wrote:
>> Mike wrote:
>> 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
> 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
Thanks Terry, I appreciate your assistance.
I was mixing my application tests with integration tests (testing against a
changing system). My new method will be: Run the integration test, this will
save a JSON file to my machine. A successful run will pass all tests and
leave me with a file on my machine.
When running application tests the setup will load the JSON file from the
machine and my tests will be based on this. This will give me the separation
I'm writing a basic twitter interfacing application :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-list