TDD django Tutorial

http://www.tdd-django-tutorial.com/tutorial/1/

by urlwolf • 14 years ago

83 16 14 years ago

tdd-django-tutorial.com

kmfrk• 14 years ago

I'm sure it's a great tutorial, but the font is basically illegible in Opera on Windows 7.

A `max-width` rule in CSS would be great as well.

hjwp34• 14 years ago

thanks for pointing that out, and for the suggestion re `max-width`, Will get on it...

igorgue3• 14 years ago

I got until Unit testing the verbose name for pub_date that's not needed, nor you should unit test that, what are you testing? That functionality or 'unit' you didn't write and I bet is a test in Django.

And then it goes on and on about testing things like 'relationships'.

I've been running away from setUp and TearDown because they ruin test readability (maybe I'd just stick in the selenium browser).

Also most of the unit tests written there are not running in isolation which means... they're not unit tests! Those are integration tests.

If you base your tests in the techniques described there you are going to end up with a very slow test suite and very fragile tests (meaning stuff breaks where it shouldn't break).

I like to run:

nose: to run tests as functions not classes pinocchio: to see specs in color nose-quickunit: to find changes in my repo and figure out what test to run (when not TDDing) coverage: stats mock: mocking library

And my tests look like this:

http://cl.ly/1R2T0G282h1z331C1A2Y

or like this:

http://cl.ly/20263T1y2s402B1v2D3R

I think they're very pretty and run fast :-)

treo• 14 years ago

Your tests, or the output they produce, look awesome. Can you elaborate on your setup? Just today I was looking for an up to date introduction for testing in django, but could only find some older blog posts. So I would be glad if you could detail your setup a bit.

StavrosK• 14 years ago

The first one looks like nose with coverage, and the second like pinocchio with coverage. There are various ways to get those running with Django, but yes, a blog post would be nice.

Just don't get all caught up in 100% test coverage, it's not very useful. You should test edge cases that run the same code more than obvious cases that run new code.

igorgue3• 14 years ago

I'll write it and let you guys know :-)

I've basically been following some Ruby people for the last couple of months - and worked at a Ruby shop myself last year - they happen to know a lot more about testing than us, pythonistas, but hey, it's very good to learn, at least Mock being included into Python3 is a step in the right (well that depends what camp are you in) direction.

rguzman• 14 years ago

i second the request to elaborate on your setup. a blog post is probably most adequate.

hjwp34• 14 years ago

Hi there, author here, and thanks - that's all very valid feedback.

I totally accept the point on the first few "unit" tests being reliant on the database. I took the decision that testing behaviour, and thus introducing the Django ORM early on, would be better in terms of what the students are learning... I think that a discussion of how you could re-write those tests without using the database, perhaps in a later tutorial, would definitely be a good idea, and it could then take in some of the pros and cons of making things maximally granular...

I spend a bit of time later on discussing "testing philosophy", ie what to test and what not to test - I'd be interested in your feedback on that?

http://www.tdd-django-tutorial.com/tutorial/3/

igorgue3• 14 years ago

Late response here:

Sorry if I was rude :-). I think your example is good enough if you don't have a starting point (it happens a lot on Python) though, hope I didn't sound like I hated the article.

I think you shouldn't test what is already tested, since, if a verbose_name fails it's likely not your fault, but still the verbose_name would fail, I'd not test attributes unless they call a function of yours, .e.g.: Generating a choices tuple of tuples from a function (or classmethod) you wrote.

A friend of mine wrote this: https://github.com/gabrielfalcao/unclebob is a good learning point IMHO, but I'd recommend just reading what he did and making your own.

About the unit tests, I think they should be isolated, I have this rule, I just test the methods of a model, and don't even instantiate the model (database access could be used in __init__). At the beginning this could be hard to do, but, to me it nows comes natural since mocking 'self' is fairly easy, now, I don't unit test legacy code, so I wouldn't recommend this approach if you're not doing TDD. To deal with legacy code, I'd write the functional tests just like you did, and rewrite things with TDD (writing the unit test first).

The area where I have most issues is integration tests, it's hard to come with a convention on how and when to write them. Again, I know what an integration test is (most of the unit tests you described are integration tests), I just don't know when to use them, or when they're needed if you have functional tests or unit tests.

k_bx3• 14 years ago

It's a fantastic tutorial and I hope everyone will start testing their code at least with selenium. But.. it's still not unit-testing (and not TDD) at all. And in things like this, when you break something at the bottom, tons and tons of tests will break.

In unit-testing tests are glanular, units are small, and you build a pyramid small step after small step.

minikomi• 14 years ago

> tests are glanular, units are small

Yes. Take care what you probe!

http://medical-dictionary.thefreedictionary.com/glanular

k_bx3• 14 years ago

facepalm.jpg

hjwp34• 14 years ago

I can totally see your objection re the tests not being "unit-ey" enough... But why would you say it's not TDD?

k_bx3• 14 years ago

Because TDD is about test-driven design. And functional tests don't do any impact on design.

TDD is about creating code in a way, suitable for unit-testing and creating code step-by-step, keeping each step small and all branches tested.

TDD does these restrictions:

1. don't write line of code until you wrote failing test.

2. don't write line of test until you wrote code that "fixes" failing test.

So, by these restrictions, you will always try to cover all possible branches of your code, all possible different situations and corner-cases. While with functional tests, it's very hard to do that.

idleloops• 14 years ago

http://news.ycombinator.com/item?id=3996328

TDD django Tutorial

Related Stories