Hi Tim,
I just reviewed the online version at
http://techytim.com/django/9962/intro/tutorial05.html and I found it very clear.
Here are a few suggestions to make it even better. Some don't fit well in
inline comments, so I wrote an email instead; I hope you don't mind.
The "Why you need to create tests" section is written from the point of view of
a single developer. Complex applications will be maintained by teams. Tests
guarantee that colleagues don't inadvertently break your code (and that you
don't break theirs without knowing). If you want to make a living as a Django
programmer, you must be good at writing tests!
Another argument — but a weaker one, and I know you can't extend that section
infinitely — is that tests help identify fragile or even dead code. If you
can't test a piece of code, it usually means that code should be refactored or
removed. That idea could be postponed to a paragraph introducing coverage.py.
I recommend to remove the "descriptive comments" in code snippets, such as this
one:
# was_published_recently() should return False
self.assertEqual(future_poll.was_published_recently(), False)
It isn't useful to paraphrase the code in comments. This applies to all test
snippets in the tutorial.
A small style suggestion:
def was_published_recently(self):
return (self.pub_date >= timezone.now() - datetime.timedelta(days=1)
and self.pub_date < timezone.now())
The tests cases in "Testing our new view" should take advantage of
assertQuerysetEqual to make the assertions more readable.
https://docs.djangoproject.com/en/1.4/topics/testing/#django.test.TestCase.assertQuerysetEqual
It's the first time I encounter the pattern: "initialize objects in setUp, save
them in test cases when you need them in the database". It's a bit weird. I
think most people would use a factory, which can be as simple as:
def create_poll(self, question, days):
Poll.objects.create(question=question, pub_date=timezone.now() +
datetime.timedelta(days=days))
The stance in "When testing, more is better" is extreme, but that's probably
what beginners need to hear. Concepts such as mocking, testing layers in
isolation, unit vs. functional vs. integrations testing, using inheritance to
test combinations, etc. don't belong in a tutorial.
Finally, in "Further testing", it would be worth linking to
http://nedbatchelder.com/code/coverage/ and explaining that it's a good way to
spot untested parts of your application.
Best regards,
--
Aymeric.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
