Databases
StackOverflow2013
Postsdbo
POUnit-testing tightly-coupled models in Django
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POUnit-testing tightly-coupled models in Django
    primarykey
    data
    text
    <p>I'm new to both django and unit-testing, and I'm trying to build unit-tests for my models but have been having some difficulty.</p> <p>I have several models working closely together:</p> <p><code>Resource</code> which will maintain a file resource</p> <p><code>MetadataField</code> which represents a metadata field that can be added to resources, corresponds to a table full of fields</p> <p><code>MetadataValue</code> Matches MetadataField IDs with Resource IDs and a corresponding value, this is an intermediary table for the Resource - MetadataField many-to-many relationship</p> <p><code>MetadataSchema</code> represents a schema consisting of many <code>MetadataFields</code>. Each <code>Resource</code> is assigned a <code>MetadataSchema</code> which controls which <code>MetadataFields</code> it is represented by</p> <p>Relationships:</p> <pre><code>Resource - MetadataField : Many-to-Many through MetadataValue MetadataValue - MetadataSchema : Many-to-Many Resource - MetadataSchema : One-to-Many </code></pre> <p>I'm not sure how to write tests to deal with these models. The model testing in the <a href="http://www.tdd-django-tutorial.com/" rel="nofollow">Test Driven Django</a> tutorial seems to mostly cover initializing the objects and verifying attributes. If I do any setting up of these objects though it requires the use of all the others, so the tests will all be dependent on code that they're not meant to be testing. e.g. if I wish to create a resource, I should also be assigning it a metadata schema and values for fields in that schema.</p> <p>I've looked around for good examples of unit tested models in django but haven't been able to find anything (the django website doesn't seem to have unittests, and <a href="https://code.djangoproject.com/wiki/DjangoResources#Open-SourceDjangoprojects" rel="nofollow">these projects</a> all either have poor/missing testing or in a couple cases have good testing but almost no models used.</p> <p>Here are the possible approaches I see:</p> <ul> <li>Doing a lot of Mocking, to ensure that I am only ever testing one class, and keep the unit tests on the models very simple, testing only their methods/attributes but not that the relationships are functioning correctly. Then rely on higher level integration tests to pick up any problem in the relationships etc. </li> <li>Design unittests that DO rely on other functionality, and accept that a break in one function will break more than one test, provided it remains easy to see where the fault occurred. So i would perhaps have a method testing whether I can successfully add a <code>MetadataValue</code> to a resource, which would require setting up at least one <code>MetadataSchema</code> and <code>Resource</code>. I could then use a <code>try - except</code> block to ensure that if the test fails before the assertions dealing with what I'm actually meant to be testing, it gives a specific error message suggesting the fault lies elsewhere. This way I could quickly scan multiple failed test messages to find the real culprit. It wouldn't be possible to do this separation reliably in every test though</li> </ul> <p>I'm having a hard time getting my head round this, so I don't know if this all makes sense, but if there are best practices for this sort of situation please point me to them! Thanks</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USCiaran Phillips
    plurals
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POUnit-testing tightly-coupled models in Django
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POUnit-testing tightly-coupled models in Django
      1. This table or related slice is empty.
      1. VTUpMod
    1. COOften if the unit tests are too hard to write it can be pointing out that the design is overly complex. For instance I'm not sure I see the value of MetaDataField? Couldn't each MetaDataValue table have a colum for Resource and Value. Then you would have a table for each type of metadata. Which is a bit clearer and not too outlandish. Depending on how many different types of metadata you predict you will have of course.
      singulars
      1. POUnit-testing tightly-coupled models in Django
      1. USaychedee
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload