3 ms·

That is a great resource. Especially pulling Selenium into the picture and showing good functional testing. Thanks to the author for putting this together. Whi

That is a great resource. Especially pulling Selenium into the picture and showing good functional testing. Thanks to the author for putting this together. 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-django/ http://toastdriven.com/blog/2011/apr/10/guide-to-testing-in-...

hjwp3 14y ago
thanks! 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...
hjwp3 14y ago
Also, I'd tend to agree that testing model attributes is a bit OTT - it's very close to testing a constant... but, it really doesn't take that long, and if it provides a scaffold that makes it easier to write future unit tests on the model (eg, on a computed field), so much the better for a little nudge that encourages more test coverage...

hjwp3 14y ago

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

hjwp3 14y ago

Also, I'd tend to agree that testing model attributes is a bit OTT - it's very close to testing a constant... but, it really doesn't take that long, and if it provides a scaffold that makes it easier to write future unit tests on the model (eg, on a computed field), so much the better for a little nudge that encourages more test coverage...