Repository Unit Test Documentation

The Repository Framework contains a set of unit tests.

These tests use Python 2.3's built-in unittest framework.

Executing the tests

The tests for a Chandler module can be executed by changing into a module directory, in this case $CHANDLERHOME/Chandler/respository and executing hardhat.py -t. This will run all of the unit tests for the module, include tests in sub-modules/directories.

You can also execute a single test by executing it with hardhat.py

Current tests

At the moment there are four sets of unit tests.

1. The first set of unit tests exercise the functionality of the Repository itself. These tests are found in repository/tests:
   
   • TestRepository.py - tests Repository API
     
   • TestRepositoryBasic.py - tests ability to create and destroy repositories
     
2. The second set of unit tests exercise features of the Chandler data model. These tests are found in repository/tests:
   
   • TestBinary.py - Test binary Large OBjects (LOBs)
     
   • TestItems.py - Test functionality of items, focusing on parent child functionality
     
   • TestKinds.py - Test functionality of kinds
     
   • TestLiteralAttributes.py - Test functionality of literal attributes
     
   • TestPersistentCollections.py - Test the python like behavior of multi-valued reference collections
     
   • TestReferenceAttributes.py - Test functionality of reference attributes
     
   • TestText.py - Test textual LOBs
     
3. The third set of unit tests exercise features of the Chandler parcel system. These tests are found in repository/parcel/tests:
   
   • TestDependency.py - @@@Morgen
     
   • TestItems.py - @@@Morgen
     
   • TestParcelLoader.py - @@@Morgen
     
4. The last set of unit tests are really performance tests that are leveraging the unittest framework. These test are found in repository/tests:
   
   • TestPerfWithRSS.py -Simple stress performance test of the repository that tries to write and read RSS feed items into the respository
   • Profile Tests - profileBase.py along with individual TestRepository^?*.py tests to create multiple instances of each Kind -- MikeT
     Alias, Attachment, Attribte, Calendar, Contact, Contactname, ContactSection^?, ContentItem,
     Conversation, ConversationLine^?, EmailAccount^?, EmailAddress^?, Enumeration, Item, Location,
     MailMessage^?, Note, Parcel, PhoneNumber^?, Playlist, Project, RecurrancePattern^?, Reminder,
     StreetAddress^?, Task, Taxon, Type
     

Tests that ought to be written:

We could use help on fleshing out these tests even more. Here are some ideas for future tests:

• Thread/Concurrency tests - tests that use more than one thread thread to read and write data to the repository
• Versioning Conflict tests - tests to make sure that the versioning in the concurrency control system are working
• test for toXML in TestItems.py
• test lots more good and bad values in TestTypes.py
• more tests for Text and Binary LOBs
• test all the operations on python lists in TestPersistentCollections.py
• use something like pester to help find tests that are needed
• additional performance tests:
  • modify the current RSS based test to use Text LOB's
  • modify the current RSS based test to use mulitple threads
  • a test that involves traversing the object graph by tracing a long string of attributes

-- TedLeung - 05 Jan 2004