It might be a nice little module for Prepared to h...

# opensavvy

[dave08]

It might be a nice little module for Prepared to handle getting resource files... they are usually used as test input, or test setup maybe inside a prepared block having a getFromResource(name: String): String?

[CLOVIS]

That could go nicely into compat-filesystem . What kind of things do you do with the resources once you read them?

[dave08]

Use sql files to init dbs, in a current project I need to load up rss feed content as test data. I might also use them to compare test results to...

[dave08]

Currently I don't have access to the test class inside the prepared block, so I had to hard code a test class name to get them...

[CLOVIS]

Can you write a short example of what you would do without using Prepared, what you did with it, and what the problems are? So I better understand what's blocking you + what could be improved

[dave08]

I also had to do something ugly like that for support with okey-doke approval testing:

inline fun <reified T> preparedApproval() = prepared {
    val name = T::class.java.simpleName + "-" + environment.testName
    Approver(name, Sources.`in`(File("src/test/kotlin"), T::class.java.`package`))
}

val approver by preparedApproval<PodcastRssImporterSpec>()

Example for resources:

fun getContentFromResources(path: String) =
    SomeSpec::class.java.classLoader.getResourceAsStream(path)?.let {
        it.bufferedReader().use { reader -> reader.readText() }
    }

val rssExtractor by prepared {
   RssExtractor(getContentFromResources("somefeedInResources.xml"))
}

Improved:

val rssExtractor by prepared {
   // getResource would be in the TestDsl and use the current test class's resources
   RssExtractor(getResource("somefeedInResources.xml"))
}

[dave08]

A minimum improvement could be at least to have the test KClass in the TestDsl's environment...

[CLOVIS]

Created an issue with my ideas and what questions need to be answered: https://gitlab.com/opensavvy/groundwork/prepared/-/issues/66

[dave08]

I think it's a very nice touch to replace the approval testing like that, but I'm not sure if the best thing is to generate those approval files in the resources folder. Both frameworks I currently know about use the test's folder and name the file according the the test class and the current test. Also, I'm a bit afraid that real resource files might be overwritten accidentally before committing to Git...

[dave08]

I also commented there about the questions asked

[CLOVIS]

I'm not sure if the best thing is to generate those approval files in the resources folder

Where else would you expect to find them?

[CLOVIS]

The last time I did approval testing was in the Python world, so I don't really know what's standard on the JVM side

[dave08]

Both frameworks I currently know about use the test's folder and name the file according the the test class and the current test.

[CLOVIS]

Hm. Do they require Gradle config?

[dave08]

Http4k uses this one: https://github.com/dmcg/okey-doke/tree/master

[dave08]

And there's also this one: https://github.com/approvals/ApprovalTests.java

[CLOVIS]

If the resources are in the same folder as the code, and it doesn't require Gradle plugin, then I don't think they use ClassLoader.getResource at all 🤔

[dave08]

They don't require gradle config, they do things the "dirty way" using junit extensions and/or class package to find the path

[CLOVIS]

Can you create another thread in the issue discussing that? I don't have time to look into it in details at the moment, sorry 😕

[dave08]

They don't, I originally didn't mean to rewrite approval testing, I meant really testing more static results that can be manually produced. But if prepared would have it's own approval testing, that would be amazing! There are too few of those, and absolutely none in Kotlin or KMP... it really does avoid having to write humoungous asserts to properly test more complex result structures.

I also don't really have too much time now, but I'll try to get back to this in the next few days to update the issue. Thanks!