```@Test testSaveSubscribers() { val queries =...
# test
u
Copy code
@Test testSaveSubscribers() {
    val queries = SubscriberQueries(JdbcDriver)
    queries.insertAll( .. seed with some data) <--- Is this okay? seeding a dependency?

    val dao = SubscriberDao(queries)
    dao.saveSubscribers(listOf( ... ))

    assertThat(dao.allSubscribers()).isEqualTo(...) <---- This? What if allXyz() won't be part of public api?
    assertThat(queries.selectAll()).isEqualTo(...) <---- Or this when allXyz() is not available? Isn't asserting on a dependency weird?
}
c
I think thats a perfectly valid way to write a model test.
i have never used sqldelight, but you can probably create different queries that you just use from your test
u
yes I can. However I heard people saying one should assert on the public api or the thing under test
c
ok but if you care about how your database looks, the writing to database tables is also an api
also if you want to test the writing to the db without testing the reading too you have to read from the database somehow
the key is to keep the classes that are tied so the database as small as possible and have not much logic in them. and to create a fresh database for each of your tests or run them in a transaction, to be able to run database tests in parallel
u
Meaning you wouldnt put diffing logic a Dao object as I have?
c
if you can do the diffing logic outside its better to do that. I really recommend that destroyallsoftware screencast i posted in my first reply