I’m writing tests for a Django application that uses an external data source. Obviously, I’m using fake data to test all the inner workings of my class but I’d like to have a couple of tests for the actual fetcher as well. One of these will need to verify that the external source is still sending the data in the format my application expects, which will mean making the request to retrieve that information in the test.
Obviously, I don’t want our CI to come down when there is a network problem or the data provider has a spot of downtime. In this case, I would like to throw a warning that skips the rest of that test method and doesn’t contribute to an overall failure. This way, if the data arrives successfully I can check it for consistency (failing if there is a problem) but if the data cannot be fetched it logs a warning so I (or another developer) know to quickly check that the data source is ok.
Basically, I would like to test my external source without being dependant on it!
Django’s test suite uses Python’s unittest module (at least, that’s how I’m using it) which looks useful, given that the documentation for it describes Skipping tests and expected failures. This feature is apparently ‘new in version 2.7’, which explains why I can’t get it to work – I’ve checked the version of unittest I have installed on from the console and it appears to be 1.63!
I can’t find a later version of unittest in pypi so I’m wondering where I can get hold of the unittest version described in that document and whether it will work with Django (1.2).
I’m obviously open to recommendations / discussion on whether or not this is the best approach to my problem 🙂
[EDIT – additional information / clarification]
As I said, I’m obviously mocking the dependancy and doing my tests on that. However, I would also like to be able to check that the external resource (which typically is going to be an API) still matches my expected format, without bringing down CI if there is a network problem or their server is temporarily down. I basically just want to check the consistency of the resource.
Consider the following case…
If you have written a Twitter application, you will have tests for all your application’s methods and behaviours – these will use fake Twitter data. This gives you a complete, self-contained set of tests for your application. The problem is that this doesn’t actually check that the application works because your application inherently depends on the consistency of Twitter’s API. If Twitter were to change an API call (perhaps change the URL, the parameters or the response) the application would stop working even though the unit tests would still pass. (Or perhaps if they were to completely switch off basic authentication!)
My use case is simpler – I have a single xml resource that is used to import information. I have faked the resource and tested my import code but I would like to have a test that checks the format of that xml resource has not changed.
My question is about skipping tests in Django’s test runner so I can throw a warning if the resource is unavailable without the tests failing, specifically getting a version of Python’s unittest module that supports this behaviour. I’ve given this much background information to allow anyone with experience in this area to offer alternative suggestions.
Apologies for the lengthy question, I’m aware most people won’t read this now.
I’ve ‘bolded’ the important bits to make it easier to read.
I created a separate answer since your edit invalidated my last answer.
I assume you’re running on Python version 2.6 – I believe the changes that you’re looking for in unittest are available in Python version 2.7. Since unittest is in the standard library, updating to Python 2.7 should make those changes available to you. Is that an option that will work for you?
One other thing that I might suggest is to maybe separate the “external source format verification” test(s) into a separate test suite and run that separately from the rest of your unit tests. That way your core unit tests are still fast and you don’t have to worry about the external dependencies breaking your main test suites. If you’re using Hudson, it should be fairly easy to create a separate job that will handle those tests for you. Just a suggestion.