Right but in 5.0 you can. I'll double check that there's no changes required from a user perspective

# kotest

[sam]

Right but in 5.0 you can. I'll double check that there's no changes required from a user perspective

[dave08]

I think I'm missing something... is there some kind of documentation on best practices in making extensions/listeners?

[sam]

Not yet. Once 5.0 is out I plan to overhaul the docs on this. If you have specific questions I can answer here.

[dave08]

Say something like this:

class KtorExtension(val module: Application.() -> Unit) : TestListener {
    lateinit var appEngine: TestApplicationEngine

    lateinit var clientEngine: HttpClientEngine


    override suspend fun beforeTest(testCase: TestCase) {
        appEngine = TestApplicationEngine(createTestEnvironment())
            .also { it.application.module() }

        clientEngine = TestHttpClientEngine.create { app = appEngine }

        appEngine.start()
    }

    override suspend fun afterTest(testCase: TestCase, result: TestResult) {
        appEngine.stop(0L, 0L)
    }
}

is this the right way to do it?

[dave08]

Or should I be using an extension?

[sam]

Yep that's fine, although I would do this:

class KtorExtension(val module: Application.() -> Unit) : BeforeTestListener, AfterTestListener {
    lateinit var appEngine: TestApplicationEngine

    lateinit var clientEngine: HttpClientEngine


    override suspend fun beforeTest(testCase: TestCase) {
        appEngine = TestApplicationEngine(createTestEnvironment())
            .also { it.application.module() }

        clientEngine = TestHttpClientEngine.create { app = appEngine }

        appEngine.start()
    }

    override suspend fun afterTest(testCase: TestCase, result: TestResult) {
        appEngine.stop(0L, 0L)
    }
}

[dave08]

Why?

[sam]

Because TestListener is just a combination of 10 interfaces that is around for legacy reasons. It won't be removed though.

[dave08]

And so how are extensions different, and when would they apply?

[sam]

An extension is anything you write that plugs into the kotest lifecycle - so before/after test/spec/project / etc.
A listener is an older term we had that basically means "an extension that is read only". So notice in your example that you are notified of before/after test but you can't "change the engine". So that's a listener.
An extension is just more powerful can do things like override test results, or skip tests entirely, etc.

[dave08]

So why are you deprecating listener(...) if it has a different purpose?

[sam]

because inside the code base listener extends extension. A listener is an extension, it's just a term for "simple extension" that really serves no purpose being it's own interface.

[sam]

TestListener won't be renamed as it's used by everyone, but what does this do:

interface Listener: Extension

[sam]

It's irrelevant because internally, the code works on

interface Extension

[sam]

Listener is just a marker interface serving no purpose other than to fuel discussions like this on "what is listener vs extension"

[dave08]

Oh... that's a bit confusing on the user's side though... Since we're supposed to know that a listener is just another extension... after you explained it, it seems like both are useful... but you're right that having two ways to install the same thing isn't great either... I wonder if there's a way to make all this clearer.

[sam]

This is meant to make things clearer. So instead of

class MyTest : FunSpec() {
  override fun extensions() = listOf(foo)
  override fun listeners() = listOf(bar)
}

[sam]

Just do

class MyTest : FunSpec() {
  override fun extensions() = listOf(foo, bar)
}

[sam]

everything is an extension, regardless of whether it's called an extension, a listener, or a filter, or a foo

[sam]

I'll write up a page that goes over this in detail to hopefully make things clear and I'll circulate before we release 5.0

[dave08]

Yeah, but it's not to evident that BeforeTestListener is an extension when the concept of Extension is something a bit more flexible. I guess the docs could be a big help do disambiguate things though...

[sam]

Right, the nomenclature certainly isn't the best, for legacy reasons

[sam]

but I think it's a clearer message to say "listeners are just extensions anyway" than "we have two parallel hierarchies of stuff"

[dave08]

By the way, I was wondering what would be the most appropriate way to integrate Dagger2 into an extension to to dependency injection... also having a way to use the component's val's and functions without aliasing them val dep1 get() = component.dep1() would be nice...

[dave08]

I'd have to hook on to the test class creation somehow and maybe even make it a delegate of the component...

[sam]

How does dagger integrate normally, outside of tests ?

[sam]

is there a method you call like "setup my class" ?

[dave08]

If I do:

class SomeSpec @Inject constructor(val dep1: Dep1) { ... }

// component interface
interface TestComponent {
   val someSpec: SomeSpec
}

// Will generate DaggerTestComponent, and then to build the graph:
val component = DaggerTestComponent.builder().build()

// And to retreive the injected spec:
component.someSpec

[sam]

how does someSpec get inside the component ?

[dave08]

Dagger2 generates DaggerTestComponent that derives from TestComponent with all the object initialization code

[sam]

Through a compiler plugin ?

[dave08]

Through kapt

[sam]

You could write something like:

class DaggerExtension : PostInstantiationExtension {
  override suspend fun instantiated(spec: Spec): Spec {
    // get component somehow ? by casting ?
    return component.someSpec
  }
}

[sam]

Or look at

ConstructorExtension

[sam]

which allows you to control how the spec is created from the class

[dave08]

Thanks! I'll take a look at those.

[sam]

if you get stuck I can help

[dave08]

Ok, a bit funny... I have say:

interface TestComponent {
  fun inject(spec: SomeSpec)
}

val component = DaggerTestComponent.builder().build()

class SomeSpec : DescribeSpec() {
  @Inject val dep1 : Dep1
}

I have to get the PostInstantiationExtension to run component.inject(this@SomeSpec) somehow... so that dep1 gets injected...

[dave08]

But how is the extension supposed to guess that TestComponent has an inject function that takes the SomeSpec type...

[dave08]

The start was:

class  DaggerExtension<C : Any, S : KotestDbSpec>(val component: C, val injector: (S) -> Unit) : PostInstantiationExtension {
    override fun process(spec: Spec): Spec = spec.also { component/*...?*/ }
}

[sam]

Well, you could look for an annotation that tells it it's a dagger test, or you could do some reflection magic if something is possible there, or you could just say this extension should only be added to dagger specs and you cast and catch

[dave08]

class  DaggerExtension<C : Any, S : KotestDbSpec>(val component: C, val injector: C.(S) -> Unit) : PostInstantiationExtension {
    override fun process(spec: Spec): Spec = spec.also { component.injector(spec as S) }
}

?

[sam]

I don't know anything about dagger. How do you know something is dagger normally?

[sam]

Does it generate a new class, or new functions, what does kapt add

[dave08]

A DaggerTestComponent gets generated with something like:

@Override
  public void inject(GetCustomerSpec getCustomerSpec) {
    injectGetCustomerSpec(getCustomerSpec);
  }

  private GetCustomerSpec injectGetCustomerSpec(GetCustomerSpec instance) {
    GetCustomerSpec_MembersInjector.injectCustomerRepo(instance, customerTestRepoProvider.get());
    return instance;
  }

[sam]

Is it called DaggerTestComponent and is there one per spec ?

[sam]

or one giant one

[dave08]

The generated class is Dagger{name of the component interface}

[sam]

So then inside your extension, could you do

Class.forName(Dagger + kclass.name) to get the class reference

[sam]

Then you can use reflection to create the instance, call inject

[sam]

that could easily be a ConstructorExtension

[dave08]

And for each spec that needs injection, I would have to add an fun inject(spec: SomeSpec) , I don't need to create the spec, I just need to run DaggerTestComponent.builder().build().inject(this) before each test or spec.

[dave08]

I just need to find the appropriate inject function...

[dave08]

I suppose Spec doesn't contain it's type or something...

[sam]

Spec::class is the spec's class

[sam]

Right, so this is a start

class DaggerExtension : PostInstantiationExtension {
   override suspend fun instantiated(spec: Spec): Spec {
      val c = Class.forName("Dagger" + spec::class.name) // this would be DaggerMyTest
      val m = c.declaredMethods.find { it.name == "builder" ) // get builder() method
      val builder = m.invoke(null) as DaggerBuilder
      DaggerBuilder.build().inject(spec)
      return spec
   }
}

[sam]

I didn't test any of that but it's probably in the right direction

[dave08]

Class.forName("Dagger" + spec::class.name) isn't the spec, it should be Class.forName("Dagger" + componentInterface::class.name) ... say TestComponent would have DaggerTestComponent implementation generated that contains a function inject(spec: SomeSpec) which is the function that I need to run...

[sam]

Well it's a start anyway

[sam]

doing a prod release now, back later