Interactive browser-based console for any Python Gist
pythonanywhere.com30 pointsby hjwp311 comments
instantiate a model
assign some attributes to it
save it
retrieve it from the database
assert the retrieved object has the attributes assigned earlier, with the correct values & types (including a datetime value)
instantiate an object
assert it is a subclass of django's model types
assert it has default attributes with correct default types
finally, use some django voodoo or metaclass inspection to confirm that the datetime field, whose default value is "None", is actually a working datetime field...
> On the Merits of Trivial Tests for Trivial Functions
> In the short term it may feel a bit silly to write tests for simple functions and constants.
> It’s perfectly possible to imagine still doing “mostly” TDD, but following more relaxed rules where you don’t unit test absolutely everything. But in this book my aim is to demonstrate full, rigorous TDD. Like a kata in a martial art, the idea is to learn the motions in a controlled context, when there is no adversity, so that the techniques are part of your muscle memory. It seems trivial now, because we’ve started with a very simple example. The problem comes when your application gets complex—that’s when you really need your tests. And the danger is that complexity tends to sneak up on you, gradually. You may not notice it happening, but quite soon you’re a boiled frog.
> There are two other things to say in favour of tiny, simple tests for simple functions.
> Firstly, if they’re really trivial tests, then they won’t take you that long to write them. So stop moaning and just write them already.
> Secondly, it’s always good to have a placeholder. Having a test there for a simple function means it’s that much less of a psychological barrier to overcome when the simple function gets a tiny bit more complex—perhaps it grows an if. Then a few weeks later it grows a for loop. Before you know it, it’s a recursive metaclass-based polymorphic tree parser factory. But because it’s had tests from the very beginning, adding a new test each time has felt quite natural, and it’s well tested. The alternative involves trying to decide when a function becomes “complicated enough”, which is highly subjective, but worse, because there’s no placeholder, it seems like that much more effort, and you’re tempted each time to put it off a little longer, and pretty soon—frog soup!
> Instead of trying to figure out some hand-wavy subjective rules for when you should write tests, and when you can get away with not bothering, I suggest following the discipline for now—as with any discipline, you have to take the time to learn the rules before you can break them.