unittest - what is the best way to reuse test data?

[Terry Reedy]

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:
> 
>         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