What To TestThe

What To TestThe topic

• Test with resolver methods: Even though you can instantiate a provider object in ProviderTestCase2, you should always test with a resolver object using the appropriate URI. This ensures that you are testing the provider using the same interaction that a regular application would use.
• Test a public provider as a contract: If you intent your provider to be public and available to other applications, you should test it as a contract. This includes the following ideas:
  • Test with constants that your provider publicly exposes. For example, look for constants that refer to column names in one of the provider's data tables. These should always be constants publicly defined by the provider.
  • Test all the URIs offered by your provider. Your provider may offer several URIs, each one referring to a different aspect of the data. The Note Pad sample, for example, features a provider that offers one URI for retrieving a list of notes, another for retrieving an individual note by it's database ID, and a third for displaying notes in a live folder.
  • Test invalid URIs: Your unit tests should deliberately call the provider with an invalid URI, and look for errors. Good provider design is to throw an IllegalArgumentException for invalid URIs.
• Test the standard provider interactions: Most providers offer six access methods: query, insert, delete, update, getType, and onCreate(). Your tests should verify that all of these methods work. These are described in more detail in the topic Content Providers.
• Test business logic: Don't forget to test the business logic that your provider should enforce. Business logic includes handling of invalid values, financial or arithmetic calculations, elimination or combining of duplicates, and so forth. A content provider does not have to have business logic, because it may be implemented by activities that modify the data. If the provider does implement business logic, you should test it.