Skip to main content

Testing With Python: The Django Way Part 1


One thing I really slacked on while developing AWiKi (it's on internal network hence can't show you) was testing. Maybe that's not the right way to put it. It's not like I didn't test. In fact, I did a lot of testing. A lot of painstaking manual testing. For every change. So, in a way it was really the opposite of slacking. It was working a whole lot harder than I really needed to. It was also dumb. 
Being conversant in conventional Automation methods I quickly tried my hands on automating a few scenarios using QTP and Selenium. But this soon led me to a more severe problem: I was surrounded with uncountable number of scenarios I needed to automate and soon it was eating more time than I was devoting in the development.
Soon I realized What I did slack on, was figuring out how Django's unit testing framework worked. Well, no more! In fact, it's really easy to set up. Writing tests can also be somewhat painstaking when it comes to ensuring you've covered every possible input, but at least that pain is an investment that repays itself every time you make a change to the program and you can know right away if you've broken something that used to work. 
As usual the Django documentation is excellent. Highly recommend for learning everything about testing with Django. What I hope to do here is give a brief overview of what you need to do some basic testing. Partly as a reminder for myself on future projects, and hopefully to help out anyone in the same position I was before I started.

Getting Started 

If your Django app is relatively new, the startapp command already created a tests.py file when you ran it to set up your app. This file includes some helpful examples, like so:

"""
This file demonstrates two different styles of tests (one doctest and one
unittest). These will both pass when you run "manage.py test".

Replace these with more appropriate tests for your application.
"""

from django.test import TestCase

class SimpleTest(TestCase):
    def test_basic_addition(self):
        """
        Tests that 1 + 1 always equals 2.
        """
        self.failUnlessEqual(1 + 1, 2)

__test__ = {"doctest": """
Another way to test that 1 + 1 is equal to 2.

>>> 1 + 1 == 2
True
"""} 

If you don't already have a tests.py file, the important things to note are that you have to import the TestCase class from django.test and create a new class which subclasses it. Each method defined in this class will correspond to one test, usually the test of a corresponding function in your views.py file. To test a particular function from views.py, define a method with the name test_functionname.

Test data 

Now, I'm guessing your application probably manipulates some sort of data. As a matter of fact mine does a lot. The Django test runner is kind enough to setup and destroy a complete test database for the purposes of running your tests. There's two important consequences to this. First, the database user specified in your settings.py file has to have the necessary permissions to create and destroy databases. So, make sure that's the case. Second, if you already have a test database set up on your development machine (or wherever), with data you've inserted during your manual tests, the test runner won't have access to any of it.
To get some data for your tests, you can try exporting the data already in your test database with Django's dumpdata command. The test runner can then load it as a fixture. Honestly, I just couldn't get this to work. Some googling about the errors I was getting seemed to indicate that I wasn't the only one having problems with it. The update to natural keys announced for Django 1.2 seemed like it would help, but I've still been unsuccessful, so far. In any event, I plan on keeping an eye on future developments to see if there's any improvements in this area.
In the meantime, I went ahead and did it the hard way. I created a separate file called testsetup.py. I imported all the models for my project and defined a function also called testsetup. All this function does is create a few instances for each model with all their various possible configurations. By defining a method called setUp in the new class I created in tests.py and calling this function there, all of the necessary data will be added to the test database before the tests are run.


class ViewTest(TestCase):

    def setUp(self):
        testsetup()


And now we will delve into the requests. But that's for another day (Part 2)

Popular posts from this blog

LibrePlanet 2017: Liberating your open source experience

LibrePlanet is a yearly gathering of free software activists, users, and contributors—and, it's my favorite conference of the year. Here's why.
LibrePlanet is run by the Free Software Foundation, and has steadily evolved from a yearly members' meeting with presentations from staff and board members to a full blown two-day conference with speakers and attendees from all over the world. The event brings people who care about free software together to talk about the future of the movement, address current challenges, and celebrate successes.
Prelude I was invited to give a talk at LibrePlanet 2017 on 25th March at MIT, in Cambridge, Massachusetts representing Mozilla as a Tech Speaker. I reached Boston on 25th early morning. Around 1 AM. The journey itself was awesome till I realized that you don't get Uber or Lyft at Boston Airport.

Not that the apps don't function there. They work! Just no driver will be ready to pick you up from Airport at that time. After trying t…

Maximum Call Stack size exceeded: My mishap with nodejs and MongoDB

Working with nodejs is always an adventure and mix MongoDB with it, and it becomes very interesting for a nodejs enthusiast like me.

While working on a pet project involving Native MongoDb driver and nodejs I encountered a weird problem.

RangeError:MaximumcallstacksizeexceededAs usual my first thought was to Google out what I was facing and googling it out led me to the following to links.RangeError: Maximum call stack size exceededCalling Model.collection.save() RangeError: Maximum call stack size exceeded Also In some posts in MongoDB’s forum I saw that peoples said saving in `process.nextTick` or wrapping the call function in `parseInt` will also fix the problem, but it most certainly didn't work for me.So I started digging in on my own and soon enough found the reason.

If you’re trying to save a document and saving process somehow exited with an RangeError: Maximum call stack size exceeded exception, it’s related to what you want to save in the database. I had this problem a…

All Hands 2016: MozLondon, A recount

I recently had the opportunity to take part in Mozilla All Hands 2016 (a.k.a #MozLondon). Mozilla All hands. All Hands are bi-yearly events of Mozilla where all the paid staff from different teams around the globe meet with each other along with a handful of invited volunteers to disscuss about future projects and get some work done! This year it was in London and just immediately before Brexit (I actually didn't even know about it before I went there). It was a work week, so essentially the event spanned from Monday to Friday. I arrived at LHR on Monday morning, and then there was the awesome Heathrow Express which took me to Paddington, just a 7 mins walk away from Hilton Metropole where I was staying with a bunch of other people. The event started with all of us having an evening orientation familiarizing us with rules and regulations along with Code of Conduct(that turned out to be really important later on...).  Tuesday started with a Planery. Which you can see if you are lo…