assertk
assertk copied to clipboard
Assert failures throw AssertionError
#410 Replace calls to assertFails{} with assertFailsWith<AssertionError>{}, which is more specific and avoids cases where assertk's code throws an unexpected exception. This also allows cleaning up a couple of cases where this was already being done by comparing the exception class to an expected class.
I'm able to reproduce the tests failing the build locally (had wondered if it was something about my local environment before pushing), but I'm not sure how to fix them and would appreciate help. They all seem to failures for coroutines tests on JS; the test report on CircleCI doesn't include the stack trace but (at least for most) it looks something like
AssertionError: Expected an exception of class AssertionError to be thrown, but was completed successfully.
at Object.captureStack(C:\Users\Dominic\Documents\GitHub\assertk\build\js\packages_imported\kotlin\1.5.30\src\kotlin\builtins.kt:103)
at AssertionError.constructor(C:\Users\Dominic\Documents\GitHub\assertk\build\js\packages_imported\kotlin\1.5.30\kotlin.js:38897)
at <global>.new AssertionError(C:\Users\Dominic\Documents\GitHub\assertk\build\js\packages_imported\kotlin\1.5.30\src\kotlin\exceptions.kt:85)
at DefaultJsAsserter.fail(C:\Users\Dominic\Documents\GitHub\assertk\build\js\packages_imported\kotlin-test\1.5.30\src\main\kotlin\kotlin\test\JsImpl.kt:23)
at DefaultJsAsserter.fail(C:\Users\Dominic\Documents\GitHub\assertk\build\js\packages_imported\kotlin-test\1.5.30\src\main\kotlin\kotlin\test\DefaultJsAsserter.kt:71)
at <global>.checkResultIsFailure(C:\Users\Dominic\Documents\GitHub\assertk\build\js\packages_imported\kotlin-test\1.5.30\src\main\kotlin\kotlin\test\JsImpl.kt:30)
at lambda.doResume(kotlin\Assertions.kt:615)
at lambda.local$closure$block(C:\Users\Dominic\Documents\GitHub\assertk\assertk-coroutines\src\commonTest\kotlin\test\assertk\coroutines\assertions\FlowTest.kt:116)
at lambda.doResume(C:\Users\Dominic\Documents\GitHub\assertk\assertk-coroutines\src\jsTest\kotlin\test\runTest.kt:10)
at lambda.CoroutineImpl.resumeWith(C:\Users\Dominic\Documents\GitHub\assertk\build\js\packages_imported\kotlin\1.5.30\src\kotlin\coroutines\CoroutineImpl.kt:47)
at DispatchedContinuation.DispatchedTask.run(C:\Users\Dominic\Documents\GitHub\assertk\build\js\packages_imported\kotlinx-coroutines-core\1.5.2\kotlinx-coroutines-core.js:28903)
at ScheduledMessageQueue.MessageQueue.process(C:\Users\Dominic\Documents\GitHub\assertk\build\js\packages_imported\kotlinx-coroutines-core\1.5.2\kotlinx-coroutines-core.js:32280)
at <global>.<unknown>(C:\Users\Dominic\Documents\GitHub\assertk\build\js\packages_imported\kotlinx-coroutines-core\1.5.2\kotlinx-coroutines-core.js:32096)
at <global>.processTicksAndRejections(internal/process/task_queues.js:77)
which is very strange since the previous assertFails{} apparently worked as expected. I figure it's something with the JavaScript-coroutines intersection which I'm not familiar with; I can just revert the changes of these few tests if the fix is unclear.
(FWIW, I've found a block like this one which includes test failure stack traces in gradle's output to be helpful, especially in debugging CI failure like this one.)
The build logs are gone, but this should be specific to the legacy JS compiler. So once #439 merges (which removes the legacy compilation) you can rebase and then this should be good.
Rebased and merged https://github.com/willowtreeapps/assertk/pull/440