I’m wondering if kotest could get snapshot tests s...

# kotest

[Piotr Krzemiński]

I’m wondering if kotest could get snapshot tests support. See https://github.com/kotest/kotest/issues/777

[Piotr Krzemiński]

we use Python in the company and heavily rely on this technique using https://pypi.org/project/pytest-snapshot/. I must admit it’s convenient

[Piotr Krzemiński]

https://github.com/pedrovgs/KotlinSnapshot doesn’t seem to be maintained anymore

[Piotr Krzemiński]

I’m willing to help implement if there’s a decision to add it

[christophsturm]

does it have to be tied to kotest, why not make it test runner agnostic?

[Piotr Krzemiński]

I consider kotest a set of functionality related to testing, a coherent whole, so I thought it can be beneficial to provide have it as first-party feature. Of course, it has its pros and cons

[sam]

I'd love to see it included

[Piotr Krzemiński]

cool! I’ll come up with API design

[phldavies]

I see no reason why it shouldn’t be as “coupled” to kotest as the assertions and property-testing components - that is to say not at all, but strongly encouraged.

[Piotr Krzemiński]

that’s my exact way of thinking

[wasyl]

How does such snapshot testing work, in general? You have to store snapshots in files, do you need e.g. Gradle plugin to wire things like up-to-date checks?

[Piotr Krzemiński]

high-level, you write in your tests “hey, here’s a piece of data - put it in the snapshot (some file)“. The test can run in two modes: snapshot validation (comparing data that was passed in a current run VS stored in the snapshot; default mode) or snapshot update (there has to be a way to enable it explicitly). In Python’s solution, it’s about calling pytest with --snapshot-update . In the library I mentioned in the thread, it’s either about calling a specific Gradle task or passing a Gradle property. I like the approach with the property because it still lets me run the tests however I like (e.g. a subset), but we can consider other options

[wasyl]

Makes sense, what I wanted to dig into is the detail of how are the snapshot files treated by the build tool. For example if those files are transparent to the build tool, then you can have a situation (in Gradle) where test tasks are up-to-date because the tests sources didn’t change, but snapshots did. Having a plugin would be definitely some effort and added complexity in the build so it’d be nice to avoid it, just wondering what the tradeoffs would be (if any)

[Piotr Krzemiński]

good point! I’ll think about it during the design

[wasyl]

Perhaps it’d be enough to have a recipe that does something like tasks.withType(Test).configureEach { inputs.add(<snapshotsPath>) } . Just thinking aloud, and I love the idea of snapshots in Kotest — I’ve been looking into some of those libraries recently myself

[Emil Kantis]

Personally I think it would be nice to just add them in src/test/resources for instance.. but perhaps that doesn't work for multiplatform?

[Emil Kantis]

Kotlin multiplatform wizard adds this to gradle config when you set up a JS/JVM project. I suppose it will make resources available on JS

tasks.named<Copy>("jvmProcessResources") {
    val jsBrowserDistribution = tasks.named("jsBrowserDistribution")
    from(jsBrowserDistribution)
}

[Piotr Krzemiński]

@Emil Kantis I won't be able to push this topic in the nearest future, please unassign me from the ticket

[Ned Twigg]

Fwiw, i integrated the selfie snapshot testing library into Kotest as a 3rd party module here: https://github.com/kotest/kotest/pull/3870