https://kotlinlang.org logo
Join Slack
Powered by
How do you deal with random values in tests? Do yo...
# test
c
How do you deal with random values in tests? Do you use them, avoid them? I wrote about my favorite approach: https://opensavvy.gitlab.io/groundwork/prepared/docs/features/random.html
👍 1
c
I now avoid all randomness in tests because I want each CI run to test exactly the same thing. When trying to find a bug i would maybe run a test with randomness locally but then from the failure of that test i would create tests with fixed data.
d
Just wondering what was wrong with Kotest @CLOVIS... why another testing library?
c
The main reason is https://opensavvy.gitlab.io/groundwork/prepared/docs/features/prepared-values.html Other reasons: • Kotest doesn't support nested tests in KJS, Prepared does • Kotest requires a compiler plugin on KJS, Prepared using the Kotlin-test runner doesn't • Kotest has poor support for kotlinx-coroutines-test because they duplicate many of its features differently, which creates confusion However, Prepared is compatible with Kotest: you can use Prepared features and syntax within a Kotest suite if you want.
d
Those prepared values look very nice! I'm wondering they couldn't be used straight in a Kotest FreeSpec....? Also, a big advantage in Kotest is the ability to run a single test or test class (the feature you're working on) easily... In prepared, currently one would need to run the whole suite every time, no?
c
Prepared values need the ability to cache data into each test execution itself. There may be a way to do this with a Kotest plugin, to be able to use them directly within a Kotest, but I don't know how to do it.
In prepared, currently one would need to run the whole suite every time, no?
Yes 😕 This is mostly a tooling issue (the test framework knows which tests exist, but Gradle doesn't let it report them, which in turns means IntelliJ cannot see them). Kotest workarounds this by having their own IntelliJ plugin, but that's very brittle (e.g. you can't create your own specs). IMO, the way forward is to have this responsibility be in the build tool, but that's not going to happen with Gradle.
Actually, this isn't true, you could specify which tests you want to run using the 
--test
argument. But IntelliJ won't fill it in for you. Also, the Kotest IntelliJ plugin is not aware of some Gradle features (IIRC it ignores java toolchains?) because it has its own run configuration type—so even when I'm working on a Kotest projet, I don't use the plugin, and thus can't run tests one-by-one anyway… so for me Prepared isn't worse in this situation, but I completely understand that it may be an important feature for many people
d
Kotest does have something... they use a 
!
prefix to denote focus on a particular test, but you'd still need to run only that test class. Something like that could be one possibility together with 
--test
but still frustrating that Intellij can't auto-complete... Most of the time, running too many tests makes it very hard to focus on the failing test that you're working on... (apart from taking more time to run)
c
That depends on the workflow, I guess. I often have a very large amounts of extremely small tests, and I prefer always rerunning all of them to check that my changes don't impact anything else
d
Btw, the docs are really amazing! The framework is also very tempting to use... my only two little problems are the mentioned running a single test, and the fact that you limit to using suite/test... I tend to use FreeSpec in Kotest.
c
(also, I recommend reading the reference for the 
:suite
module, the website doesn't mention most of the features yet 👀)
👍🏼 1
You could re-recreate the FreeSpec syntax on top of suite/test if you wanted. Personally, I prefer having a single way to do things in the library so it's easier to learn to new users
👍🏼 1
d
If there would be a way to make an extension in Kotest, I would have really wanted to adopt at least the prepared values part... but the way that Prepared handle coroutines is also very tempting... You wouldn't consider having that focus feature (at least until you have an Intellij plugin...)?
c
Can you create an issue for it? I could add focus in the Kotest compatibility module
Also, if integrated in Prepared, focus would work even for nested tests 👀 (Kotest sees all tests as top-level, even if they are declared nested in Prepared)
You can also join #opensavvy to discuss the project
d
Open in Slack
PreviousNext
Powered by