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