Describe testing strategy

[cmelchior]

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.