https://kotlinlang.org logo
Title
p

Piotr Krzemiński

02/09/2023, 12:21 PM
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

christophsturm

02/09/2023, 1:16 PM
does it have to be tied to kotest, why not make it test runner agnostic?
p

Piotr Krzemiński

02/09/2023, 1:18 PM
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

sam

02/09/2023, 1:34 PM
I'd love to see it included
p

Piotr Krzemiński

02/09/2023, 1:36 PM
cool! I’ll come up with API design
p

phldavies

02/09/2023, 1:50 PM
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

Piotr Krzemiński

02/09/2023, 1:50 PM
that’s my exact way of thinking
w

wasyl

02/09/2023, 2:13 PM
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

Piotr Krzemiński

02/09/2023, 2:18 PM
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

wasyl

02/09/2023, 2:34 PM
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

Piotr Krzemiński

02/09/2023, 2:48 PM
good point! I’ll think about it during the design
w

wasyl

02/09/2023, 3:09 PM
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

Emil Kantis

02/09/2023, 4:17 PM
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
tasks.named<Copy>("jvmProcessResources") {
    val jsBrowserDistribution = tasks.named("jsBrowserDistribution")
    from(jsBrowserDistribution)
}
p

Piotr Krzemiński

02/13/2023, 6:13 AM
@Emil Kantis I won't be able to push this topic in the nearest future, please unassign me from the ticket