Suggestions on using fixtures for ktorm database objects

[sean-abbott]

I realize that this is a bit of a long shot question, because it's not directly related to this code.

I'm trying to figure out how I can use these fixtures to test ktorm (https://github.com/kotlin-orm/ktorm). The ktorm objects are fairly complex, consisting of a singleton object that connects to the database, fronted by an abstract interface for interacting with the singleton that instantiates a proxy whenever it itself is instantiated.

Needless to say, the reflection based auto-fixture didn't work.

I tried created a class that reifies the interface, but the companion object is making that hard.

I was just wondering if anyone here has any experience or can point me in the direction of something I can read to figure this out. Or if someone here's experience says "this is probably not the right approach, don't bother".

(I asked a similar question at ktorm and it was not a question that intrigued them, so that got closed and I understand if that happens here as well)

Thank you!

[mattmook]

I'm not familiar with ktorm, so it would be good to get some more understanding of how you imagine your tests working. The way I've been using fixtures in tests has been to use them to generate values returned from functions in data source classes. The data source classes functions would wrap the implementation details of the database queries and would return concrete data types I could easily use Kotlin Fixture for. With the SQL DSL style I feel this is probably the best you can achieve.

data class Employee(val name: String)

interface DataSource {
    fun employeesCalledVince(): List<Emplyee>
}

class DataSourceImpl : DataSource {
    fun employeesCalledVince(): List<Emplyee> {
        return database
            .from(Employees)
            .select(Employees.name)
            .where { (Employees.departmentId eq 1) and (Employees.name like "%vince%") }
            .map { row -> 
                Employee(row[Employees.name])
            }
    }
}

Of course the other style is Entities and Column Binding. For example:

interface Department : Entity<Department> {
    companion object : Entity.Factory<Department>()
    val id: Int
    var name: String
    var location: String
}

These interfaces look very "fixturable". Really it's a case of detecting the interface extends Entity and implementing the interface using Java's dynamic proxy class API with the InvocationHandler routing the generation of any return values through the standard fixture creation. I imagine the Entity.Factory not being much harder.

Is this the right approach? Possibly... while in an ideal world I'd rather my data layer returned domain objects rather than database entities this doesn't aways make sense as databases will often have unique identifiers that may not make sense in the domain layer plus, of course, everyone has their own opinions about this too.

[mattmook]

This is a little untested, but something like the following should work for creating any Entity class:

val fixture = kotlinFixture {
    resolvers.add(0, object : Resolver {
        override fun resolve(context: Context, obj: Any): Any? {
            if (obj is KType && obj.classifier is KClass<*>) {
                val classifier = obj.classifier as KClass<*>

                if (classifier.isSubclassOf(Entity::class)) {
                    val entity = Entity.create(classifier)

                    classifier.declaredMembers.filterIsInstance<KProperty<*>>().forEach {
                        entity[it.name] = context.resolve(it.returnType)
                    }

                    return entity
                }
            }

            return Unresolved.Unhandled
        }
    })
}