inicio mail me! sindicaci;ón

Playing with django.test

January 29, 2007 at 12:54 pm · tags:

This morning I poked around the Django testing framework and altough is definitely usable as a simple testing framework (unittest and doctest) it lacks a massive fixture framework (like Rails for instance).

I also have some random problems using test.Client() for POST resulting in some HTTP 500 response instead of 200.

In the meantime I tried using twill to fulfill the holes in the testing infrastructure but it seems to be useless for our web app because the forms use an image to submit and twill understands only submit buttons.

The solution seems to be Selenium. It’s handy and powerful. I can test visually without have to remember line by line in which state am I and go back and forth from Firebug to TextMate to see what name has the view I have to check after. I’m not done testing with Selenium but I like it. It also produces Python source code I can integrate with the app.

Related posts

  • W3C Published XForms 1.0 as a Recommendation
  • Playing with RSS and XML
  • The future of user interfaces
  • The wonders of Selenium-IDE
  • EuroPython Day 3
    • Gravatar

    michele said,

    January 29, 2007 @ 3:04 pm

    At work, for a strongly interactive and AJAXy application, we are having good results with Sahi. Selenium had problems with asynchronous requests.

    Gravatar

    Christoph Neuroth said,

    January 29, 2007 @ 7:09 pm

    Hi,

    I also played around with it some days ago and for POST Requests, I allways got 301 (or 302? something like that) responses instead of 200… Do you have any clues why that is?

    “Fixtures” are being worked on as the documentation states. Don’t even know what that is though ;)

    Gravatar

    Lawrence said,

    January 29, 2007 @ 7:18 pm

    301/302 are redirects. I think you should see in the body but usually it’s not a wrong response code.

    A fixture is simply a collection of data to feed the testing framework.

    Gravatar

    Kumar McMillan said,

    January 29, 2007 @ 9:20 pm

    There is a usable patch for fixtures attached to http://code.djangoproject.com/ticket/2333

    on a separate but related note, I’m working on a standalone module, fixture (http://code.google.com/p/fixture/), which is a framework of sorts, pluggable into any test suite. I’m holding off on supporting django though, since there is so much work being done on their own fixtures api.

    Gravatar

    Lawrence said,

    January 30, 2007 @ 12:24 am

    Yes I know about that patch. I’m gonna wait until it will be merged in the trunk by the way

    Gravatar

    Jacob Kaplan-Moss said,

    January 30, 2007 @ 7:05 pm

    Indeed, I’m waiting for #2333 myself :) Stay tunned, because I think we’re almost there — there are just a few small things to iron out first.

    Gravatar

    Lawrence said,

    January 30, 2007 @ 7:28 pm

    Cool Jacob! I’ll keep on lurking django-dev ;-)

    Gravatar

    Maxime Biais said,

    February 21, 2007 @ 7:27 pm

    Hi !

    I’m using JMeter: http://jakarta.apache.org/jmeter/ to test and benchmark my django apps.

    Gravatar

    fonso said,

    March 7, 2007 @ 5:40 pm

    Christopher, Maybe your URLs didn’t have an ending slash? If they didn’t, Django is configured by default to append it and redirect to the resulting URL.

    Gravatar

    Lawrence said,

    March 7, 2007 @ 5:47 pm

    @fonso: the problem has been fixed weeks ago and I honestly tell you that I don’t remember what was it. I have to check in svn logs :-)

    Thanks anyway

    Gravatar

    Michael Trier said,

    May 5, 2007 @ 3:03 am

    Interesting that you like fixtures because most of the people I know, myself included, are always looking for alternatives. Fixtures seem like a nice idea until you get an application of any serious size or complexity. They really fall down. The consensus seems to be to put more reliance on mocking.

    Gravatar

    Lawrence said,

    May 5, 2007 @ 10:57 am

    To be honest I also used stubs in my project. The deal is using fixtures to test against data resembling the real data. That’s why they are useful in Django. Not as lean as Rails’ but not bad :-)

    RSS feed for comments on this post · TrackBack URI

    Leave a Comment