A modern programming language that makes developers happier.

kotlinlang

Am I misunderstanding how clues supposed to work? Tried `asClue` and `withClue` but I'm not seeing the clue included in a stacktrace :thread:

have a testing API like this:
```suspend fun &lt;ScreenT : Screen&gt; ScreenPresenter&lt;ScreenT&gt;.test(
  screen: ScreenT,
  testTimeout: Duration = 10.seconds,
  modelTimeout: Duration = 3.seconds,
  validate: suspend ReceiveTurbine&lt;ScreenModel&gt;.(NavigatorMock) -&gt; Unit,
) {
  val navigator = NavigatorMock()
  withTimeoutThrowing(testTimeout) {
    val dispatcher = singleThreadedDispatcher()
    val models = moleculeFlow(Immediate) { model(navigator, screen) }
      .flowOn(dispatcher)
      .onCompletion { dispatcher.cancel() }
      .distinctUntilChanged()

    models.test(modelTimeout) {
      validate(navigator)
    }
  }
  withClue("Unconsumed Navigator events") {
    navigator.goToCalls.expectNoEvents()
    navigator.exitCalls.expectNoEvents()
  }
}```

But stacktrace doesn't include the clue when `navigator.goToCalls.expectNoEvents()` assert fails

Untitled

What does the `expectNoEvents` definition look like?

<https://github.com/cashapp/turbine/blob/84d977d3f5d8d0479272fe1bec58cb2bd0914377/src/commonMain/kotlin/app/cash/turbine/Turbine.kt#L202>

<https://github.com/cashapp/turbine/blob/84d977d3f5d8d0479272fe1bec58cb2bd0914377/src/commonMain/kotlin/app/cash/turbine/channel.kt#L253>

Looks like we currently don't intercept non-kotest `AssertionError` s.. I think it can be fixed though. For now I think you could wrap it with `shouldNotThrowAny { }`, i.e
```  withClue("Unconsumed Navigator events") {
    shouldNotThrowAny {
      navigator.goToCalls.expectNoEvents()
      navigator.exitCalls.expectNoEvents()
    }
  }```


&gt; I think it can be fixed though
Looked into it a bit, and it seems a bit complicated.. :confused:

`shouldNotThrowAny` should do it in 6.0, but not in 5.9.1

I've documented it here <https://github.com/kotest/kotest/blob/master/documentation/docs/assertions/soft_assertions.md>

Could `shouldNotThrowAny` be an implementation detail of `assertSoftly`?

From library API perspective, any reason why `assertSoftly` couldn't just call  `shouldNotThrowAny` internally to achieve the effect of making sure all errors are wrapped softly?

yeah, this is how JUnit's equivalent of `assertSoftly` work, because it takes a collection of lambdas and executes them one at a time.

OTOH `assertSoftly` takes only one parameter. so whatever is inside that lambda should not be throwing exceptions.