I’m wondering if kotest could get snapshot tests s...
# kotest
p
I’m wondering if kotest could get snapshot tests support. See https://github.com/kotest/kotest/issues/777
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
https://github.com/pedrovgs/KotlinSnapshot doesn’t seem to be maintained anymore
I’m willing to help implement if there’s a decision to add it
c
does it have to be tied to kotest, why not make it test runner agnostic?
p
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
s
I'd love to see it included
p
cool! I’ll come up with API design
p
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.
p
that’s my exact way of thinking
w
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?
p
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
w
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)
p
good point! I’ll think about it during the design
w
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
e
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?
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
Copy code
tasks.named<Copy>("jvmProcessResources") {
    val jsBrowserDistribution = tasks.named("jsBrowserDistribution")
    from(jsBrowserDistribution)
}
p
@Emil Kantis I won't be able to push this topic in the nearest future, please unassign me from the ticket
n
Fwiw, i integrated the selfie snapshot testing library into Kotest as a 3rd party module here: https://github.com/kotest/kotest/pull/3870
🎉 2
102 Views