We can now use kotest with the 2020 ij

I think we have enough to start putting together a 4.1 release. Then we can target a 4.2 release with kotlin 1.4 features.

Sure, I'll finish it up

I'm thinking we can release 4.1.0.RC1 tonight

@sam when kotest plugin will be out of beta version?

Today, once I release 4.1.0.RC1

I've just made some final changes to Kotest with the test path stuff, I'm testing that now and then I'll release

4.1.0.RC1 is in maven central

Plugin stable 1.0.0 has been submitted to jetbrains pending approval

@sam @LeoColman now 4.1.0.RC1 has been released, should merge docs related pull requests which were on hold for release.

yeah lets do it

I'm updating the changelog

Changelog is up: https://github.com/kotest/kotest/blob/master/CHANGELOG.md

Kotest RC2 has been released

@sam Any idea why badge for latest snapshot is showing "artifact not found" from last couple of days?

I couldn't figure it out because the jars are there in the repo

Could somebody rerun tests for https://github.com/kotest/kotest/pull/1318 ? I have failed tests in an unrelated module:

com.sksamuel.kotest.assertions.async.TimeoutTest

  Test shouldTimeout should pass if a coroutine takes longer than the given timeout[jvm] FAILED

  java.lang.AssertionError: Expected test to timeout for 5/MILLISECONDS

  Caused by: java.lang.AssertionError: Expected test to timeout for 5/MILLISECONDS


  Test shouldTimeout should fail if a coroutine finishes before the timeout[jvm] PASSED
  Test executionError[jvm] FAILED

  java.lang.AssertionError: Expected test to timeout for 5/MILLISECONDS

  Caused by: java.lang.AssertionError: Expected test to timeout for 5/MILLISECONDS

Maybe they are blinky...

If you rebase from master it should be good, as I improved them recently

No major bugs reported from 4.1.0.RC2

4.0.7 has been released.

4.1.0 will go out today as well.

I've created this as the badge on the homepage has stopped working https://github.com/badges/shields/issues/5235

4.1.0 has been released.

Thanks for all the contributors for their hard work

@LeoColman @sam We have two version of assertSoftly. One without receiver object syntax.

inline fun <T> assertSoftly(assertions: () -> T): T

and the other with receiver object

inline fun <T> T.assertSoftly(assertions: T.(T) -> Unit): T

currently any time a user uses assertSoftly .

assertSoftly {

1 shouldBe 1

}

It's always the second version with

Spec class as receiver

even when user is not intended to use that version. This is usually not a problem until user really want to use first version assertSoftly. So i have this function.

fun <T> assertNextWith(publisher: Publisher<T>, first: (t: T) -> Unit, second: (t: T) -> Unit) {
    StepVerifier.create(publisher)
        .consumeNextWith(first)
        .consumeNextWith(second)
        .verifyComplete()
}

Its being used as shown in screenshot. Upto 4.0.5 version these tests were working fine, but on upgrading to 4.1.1 it start getting compilation error. As with earlier version of kotest

it

was corresponding to the correctly to intented

journey

but now with version upgrade it correspond to the spec class unintensionally. I think we should change the signature of second version to

inline fun <T> assertSoftly(t: T, assertions: T.(T) -> Unit): T

Then its usage will be more explicit like this.

assertSoftly(person) {

name shouldBe "something"

}

Yeah that makes sense, if the new one cannot exist alongside the old one, then the new one must be changed.

I think there's a way to mark a function as "Hey, don't use your scope as the receiver"

Something like