I noticed this commit https://github.com/kotest/kotest/commit/a94c8ee87ed0fb9c3d0ce2b62d819f46a5b6d8dd and, since I'm adding broswer js to Clikt for the next release, I'm curious what sonatype issues you ran into, and did that commit fix them?

@sam Is any one using kotest 4.4.3 with kotlin multiplatform with JS target(IR backend). What i am observing without IR target Kotest is able to run js test but with IR target Kotest is ignoring the JS test. Anyone facing similar issue or any extra configuration required for IR to work with kotest. https://github.com/ashishkujoy/kotlin-js-jvm-library

FYI it doesn't look like the changelog was updated for 4.4.3

4.5.0.RC1 is out

Hi @sam, any reason this library was not upgraded?

kotest-assertions-arrow-jvm

. Thanks

Any thoughts on the next release being 5.0 and removing all the deprecated stuff we've built up over the 18 months of 4.x

If anyone wants to opine on this: https://github.com/kotest/kotest/issues/2417

👋 Figured I'd drop in here since I'm trying to contribute a bit. Kotest makes life as a Kotlin dev so much more enjoyable, so I'm trying to pay it forward a bit. I'm a self-employed contractor for a semi-large Swedish company. Company recently switched from Java to Kotlin, and I brought in kotest, mockk and some other good stuff when I joined. Hoping to spread it wider within the company going forward 🙂 I also do some smaller freelance gigs on the side. Hoping to hone my skills and become an expert on kotest to be able to advocate it further 🙂 see you around

@sam i was checking out 5.0.0 snapshot builds, and I’ve got `[java.lang.NoSuchMethodError: 'io.kotest.property.Arb io.kotest.property.arbitrary.BuildersKt.constant(io.kotest.property.Arb$Companion, java.lang.Object)']`I have a feeling that’s because some of our deps (maybe property-arrow) was compiled against kotest 4.x. in 5.x it seems like

Arb.constant

was moved to its specific kotlin file. What strategy do we have on this? i can raise a PR to perhaps change the usage of

Arb.constant

to

Arb.of

or perhaps a simple arbitrary builder (which i think didn’t move)

Hi all. just bouncing some ideas around property testing. I just got some inspiration based on some recent work in property and suspend funs, as well as @sam’s branch on prop spec. This is 100% possible with some tweaks in the proptest and PropertyContext. so before

test(...) {
  checkAll(arbFirst, arbSecond) { first, second ->
    sut.execute(first, second)
  }
}

and after

test(...) { sut.execute(arbFirst.value(), arbSecond.value()) }

It’s really mindblowing! I can imagine how many hundreds lines of code I can simplify in our current tests if kotest has this.

@Jim why did you want to move json matchers to another repo, I can't remember

afaik there's currently no solution for automatically deriving an

Arb

for a data class, right? I saw a SO question about it and started fiddling with it and made some progress. would it be ok to pursue or is someone else doing something similar? @mitch: do you know? 🙂

do you want me to bootstrap the json repo ?

What version of IntelliJ and kotlin plugin are you guys using? This feels ridiculous.. 😞

Could you have a look at this when you have some minutes to spare @sam? 🙂 https://github.com/kotest/kotest/pull/2532 I also started looking into the shrinker-thing, but nothing to share yet 🙂

You're a member of the kotest org, you can do this work on branches in the kotest repo if you prefer, then it's easier for others to contribute too

@Emil Kantis by the way, on the approach on computing cartesian product for shrinks, can we discuss this a little bit? https://kotlinlang.slack.com/archives/CSYLDDZUY/p1632354439096200 this can cause problems on combinatorial explosion if we’re not careful. That was an issue @sam and I needed to urgently fix a while back https://github.com/kotest/kotest/issues/2112

Can I get a quick look over the lifecycle docs I have added. Just seeing if they're readable, and if any suggestions on naming changes. https://kotest.io/docs/framework/spec-lifecycle.html

I’m a little confused when it comes to shrinking. Specifically if we start with a failing sample, then the input will simply be shrunk to it’s smallest possible value. Wouldn’t it be of more value to first find a succeeding sample and then shrink to try to find the “border” between success and failure?

checkAll<Int> { it shouldBeGreaterThan 1000 }

Given the above, wouldn’t it make sense that shrinking should inform me that it is succeeding for 1000, failing for 999?

@Emil Kantis what do you think about https://github.com/kotest/kotest/issues/2541

@Emil Kantis you closed off the rename inspectors ticket, do you not want to do that anymore ?

just running the tests in gradle first to make sure it downloaded everything

and change the default in the build file from IC-213 to IC-211 if its still 213

I'll raise a PR in refreshVersions for kotest-framework-datatest and fixing extensions (they've been bundled up to use a single version for all extensions, when in reality all extensions have independent versioning). Is there anything else anyone noticed is missing in refreshVersions when it comes to kotest dependencies? 🙂

Tests work at least.. but it's using something called

KtExpression.resolveType()

from

package org.jetbrains.kotlin.idea.debugger.sequence.psi

I think it has issues with expect/actual, amongst other things..

Here's where those dropdown entries are defined: https://github.com/JetBrains/intellij-community/blob/943aadf32547ef82df3690e6ee8e549cebd3b2f0/plugins/kotlin/project-wizard/core/src/org/jetbrains/kotlin/tools/projectWizard/moduleConfigurators/ModuleConfiguratorWithTests.kt#L134-L185 The reason those are in the list is because they're the only JVM test plugins bundled with intellij. So unless you can convince JB to bundle the kotest plugin, I don't think you'll be able to add it to the dropdown.

@sam should I try to get a new version of the intellij plugin out? I think repeating this, running release-workflow and reverting does the trick?

I don't know if anyone else uses test containers, but using the new mountable extensions in kotest 5.0 we can do something like this:

class DatabaseContainerTest : FunSpec() {
   init {

      val mysql = MySQLContainer<Nothing>("mysql:8.0.26").apply {
         withInitScript("init.sql")
         startupAttempts = 1
         withUrlParam("connectionTimeZone", "Z")
         withUrlParam("zeroDateTimeBehavior", "convertToNull")
      }

      val ds = install(JdbcTestContainerExtension(mysql)) {
         maximumPoolSize = 8
         minimumIdle = 4
      }

      test("read from database") {
         ds.connection.use {
            val rs = it.createStatement().executeQuery("SELECT * FROM hashtags")
            rs.next()
            rs.getString("tag") shouldBe "startrek"
         }
      }
   }
}

Is

withData

working as intended with regards to test-lifecycles? This test will never print

Hello

, for instance

class SomeTest : FunSpec(
   {
      beforeEach { println("Hello") }

      context("some data test") {
         withData("World", "Foo", "Bar") { x ->
            println(x)
         }
      }
   }
)