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

If you don't already have a 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 file. To test a particular function from, 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 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 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 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):

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.
PreludeI 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 to b…

Bringing the Focus back : Firefox Focus (Builds) for Android

Firefox Focus – A Free, Fast Private Browser! On 17th November 2016 Mozilla announced Firefox Focus. A free fast and easy to use private browser for iOS. Firefox Focus was filled with goodies. From inbuilt tracker blocking, content blockers to making privacy the first class citizen. It was all of that. Wrapped in a nice package, but only for Apple Ecosystem. The argument for having focus was to make privacy dead simple and default experience for most people out there. An excellent read is this article "Privacy made simple with Firefox Focus".
And while this was all fine, a lot of us were severely disappointed that we don't have an android version. That all changes now.
Mozilla has released a port of the Firefox Focus source code and I decided to build a port from it. And this is how it looks in my One Plus One.
If you notice it looks almost similar to its iOS counterpart. Focus blocks tracking cookies by default in its system. But there are small design c…

LinuxCon China 2017: Trip Report

Linux Foundation held a combination of three events in China as part of their foray into Asia early this year. It was a big move for them since this was supposed to be the first time Linux Foundation would hold an event in Asia. I was invited to present a talk on Hardening IoT endpoints. The event was held in Beijing, and since I have never been to Beijing before I was pretty excited for the talk. However, it turned out the journey is pretty long and expensive. Much more than a student like me can hope to bear. Normally I represent Mozilla in such situations, but the topic of the talk was too much into security and not aligned much with the goals of Mozilla at that moment. Fortunately, Linux Foundation gave me a Scholarship to come and speak at LinuxCon China which enabled me to attend LinuxCon and the awesome team at Mozilla TechSpeakers including Michael Ellis and Havi helped me get ready for the talk.

The event was held at China National Convention Center. It's a beautiful and …