Uploaded image for project: 'Realm Kotlin'
  1. Realm Kotlin
  2. RKOTLIN-162

Describe testing strategy

    • Type: Icon: Improvement Improvement
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Labels:
      None

      The unit and integration tests in Realm Java has slowly turned into a mangled mess. We should try to avoid the same situation happening with regard to the Kotlin tests.

      This issue is mostly about sitting down and defining some sort of sensible strategy for organizing tests.

      We had some initial discussions about it and a reasonable first approach seems to be to have two kinds of tests.

      io.realm.test.api: A package that only test the immediate API contract, i.e. boundary tests, exceptions being thrown, that all methods throw correctly if the Realm is closed. We should look into how many of these tests can be auto-generated from some sort of metadata.
      io.realm.test.behavior: More complex tests involving the interaction of other components, i.e. what happens in a RealmResults if items are deleted. These probably need to be maintained by hand.

      Doing the above would result in having two classes for each public API class, using Realm as an example:

      • RealmApiTests
      • RealmBehaviorTests

      We need to play around with this to see if it makes sense or if some other approach makes more sense.

            Assignee:
            Unassigned Unassigned
            Reporter:
            unitosyncbot Unito Sync Bot
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: