I realize it's a almost self-consciously ugly and it's a development tutorial, but still - a little CSS & typography goes a long way.
There are is no window decoration, and I'm fine with that.
While I understand the need to show how unit tests work do we really need to test Django's ability to save records to the database and retrieve them in part 1? I personally don't follow true TDD, especially with model fields. Am I off in left field? Is this pattern common with other developers? Or perhaps people test for a fields existence by checking _meta.fields?
The example of testing a specific attribute, verbose_name, (that is expected to be altered by the user) in part 2 and the user implemented __unicode__ method test I do think is a great example, though.
I like Daniel's summary in the "What To Test?" section at http://toastdriven.com/blog/2011/apr/10/guide-to-testing-in-...
re: the first unit test, and the saving & retrieving of records -- i know this feels a bit like "testing django", but the real intention is to test that we've set up our model with the right fields.
The alternative would be to test defaults - instantiate a model, and assert that it has attributes with the correct names for the model fields we've defined, and the correct default values... I suspect that is the more common pattern, and it's certainly what we do at work. I think it can be seen as better in the sense that it has less of a dependency on Django. OTOH, the saving and retrieving provides a useful introduction to the ORM, so it's useful for the wider tutorial. It's also a bit more in the spirit of testing desired behaviour... So, pros and cons on each side really...
Using the core Django tutorial was a great decision. Being able to recycle things that I already know, rather than learning new things (even simple tutorial steps), is nice.
The zen of python states "There should be one, and preferably only one, way to do it", which I see at the level of a line of code; However, at a higher level, I always feel like there are dozens of ways to pattern something, and none with any particular community buy-in. This leaves my integration balancing awkwardly across several different authors ideas of how things should work.
What can we do about it - How can we make the python community more opinionated? The desired end result is that software is less surprising, that common problems have a readily accessibly, highly compatible solution.
Maybe we need more snobs in Python? ;)
