assertk icon indicating copy to clipboard operation
assertk copied to clipboard

Assert failures throw AssertionError

Open dzirbel opened this issue 3 years ago • 1 comments
trafficstars

#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.

dzirbel avatar Mar 18 '22 23:03 dzirbel

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.)

dzirbel avatar Mar 18 '22 23:03 dzirbel

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.

JakeWharton avatar Mar 16 '23 03:03 JakeWharton

Rebased and merged https://github.com/willowtreeapps/assertk/pull/440

evant avatar Mar 16 '23 06:03 evant