I'm on the side of those who think testing the framework is a bad idea. Unless there is a specific business logic that needs more validation like the str representation if it's redefined or a many-to-many field that has the through attribute.
I nonetheless really enjoyed your article, well written. I discovered the setUpTestData that I've never used, but I know on some occasions it would have been handy. I hope to read more advanced Django testing from you in the futur.
I really appreciate the feedback. If I may ask: how would you define models in a TDD-manner? In my case, the process that I defined works wonderfully: I write tests on what a Model might look like (fields), run them to failure, and then write the model itself. Property assertion seems weird to me at first, then I realized it's the same thing as testing getters and setters: not that much value themselves, but more of a "cover the bases" thing.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm on the side of those who think testing the framework is a bad idea. Unless there is a specific business logic that needs more validation like the str representation if it's redefined or a many-to-many field that has the
throughattribute.I nonetheless really enjoyed your article, well written. I discovered the
setUpTestDatathat I've never used, but I know on some occasions it would have been handy. I hope to read more advanced Django testing from you in the futur.I really appreciate the feedback. If I may ask: how would you define models in a TDD-manner? In my case, the process that I defined works wonderfully: I write tests on what a Model might look like (fields), run them to failure, and then write the model itself. Property assertion seems weird to me at first, then I realized it's the same thing as testing getters and setters: not that much value themselves, but more of a "cover the bases" thing.