Intellij gradle script execution does not handle kotest assertSoftly

已回答
Avatar
Jonas Hinz
创建于

I am currently debugging the difference between the gradle script execution in cli vs. IntelliJ. 

On Execution of our gradle clean build task our custom Task testIntegration is executed. While the script succeeds in cli the same RunConfiguration of this task fails in IntelliJ. 

An example for a failing test is this one for uploading pages. Each page is received as a DTO and validated.

it("page content is empty > Status: BadRequest") {
    testApplication {
        val pageName = "test_page_4.html"
        val pageContentType = ContentType.Text.Html.toString()
        val pageSize = 0

        val client = setupClientAsUser()

        val response = client.post("/api/v1/pages") {
            contentType(ContentType.Application.Json)
            setBody(createMultiPartFormDataContent(pageName, pageContentType, pageSize))
        }

        assertSoftly(response) {
            shouldHaveStatus(HttpStatusCode.BadRequest)
            body<ErrorDto>().errorKey shouldBe ErrorKey.PAGE_CONTENT_EMPTY.key
            body<ErrorDto>().message shouldBe ErrorKey.PAGE_CONTENT_EMPTY.message
        }
    }
}
route("/pages") {
	post {
    	val multiPartData = call.receive<MultiPartData>()
    	val dto = multiPartData.toDto()
    	val page = pageService.addPage(dto.name, dto.content).toDto()
    	call.respond(HttpStatusCode.Created, page)
	}
}
 data class PageRequestDto(
    val name: String = "",
    val type: ContentType = ContentType.Any,
    val content: ByteArray = byteArrayOf(),
) {
    // Validates file-item for name, content-type and content size
    init {
        require(name != "") { ErrorKey.PAGE_NAME_EMPTY }
        require(type == ContentType.Text.Html) { ErrorKey.PAGE_TYPE_NOT_ALLOWED }
        require(content.isNotEmpty()) { ErrorKey.PAGE_CONTENT_EMPTY }
        require(content.size < PAGE_CONTENT_MAXSIZE) { ErrorKey.PAGE_CONTENT_EXCEEDS_MAXSIZE }
    }
}
exception<Throwable> { call, cause →
    if (cause.rootCause is IllegalArgumentException) {
        val errorString = cause.rootCause?.message.toString()

        // find the corresponding error key or use the unknown error as fallback
        val error = ErrorKey.from(errorString) ?: ErrorKey.UNKNOWN_ERROR

        call.respond(HttpStatusCode.BadRequest, ErrorDto from error)
    }
}

While the thrown InvalidArgumentException through require is handled by StatusPages and are currently working in local testing and gradle script execution through cli, IntelliJ stops the execution directly when a InvalidArgumentException is thrown. 

Is this a configuration error on our side or a bug in IntelliJ? Any ideas on this topic? Most search results on  differing results from gradle cli or IntelliJ mention a failure in cli but tests succeeding in IntelliJ - here it is the other way round.

Votes

0

分享

4 条评论
Avatar
Roman Vatagin
创建于

Hello, Jonas!

Could you please make sure that “Build and run using” and “Run tests using” options are set to “Gradle”?

If they are, could you also share a screenshot of the Run Configuration you are using to run the tests from IDEA and, if possible, a sample Project to reproduce the issue?

0
Avatar
Jonas Hinz
创建于

Hi Roman

First your questions: Yes those options are set to “gradle” (see screenshot). Im working on a sample project, but since our project is a student project we are a bit slow on that front.

Secondly i must admit two errors:
1. The title “does not handle kotest assertSoftly” is seemingly wrong. When using the debugger on “./gradlew clean build” no breakpoints in our tests are reached. Using the kotest plugin and executing just the mentioned integration-test the same breakpoints are reached - so i assume there is just something wrong in our configuration. Notably the execution of just one test does not show the behaviour described in my first post
2. The Build-Script does *not* fail. It just lists all thrown errors in the Run-Tab and marks the whole execution with a red exclamation-mark. (See screenshots)

 

0
Avatar
Roman Vatagin
创建于

Jonas Hinz Thank you for the update!

So the issue is with how IDEA displays failed asserts from assertSoftly blocks?

I believe, this might be expected behavior, as some of the asserts do fail and IDEA is meant to inform you which ones did.

0
Avatar
Jonas Hinz
创建于

Hi Roman,

I solved my problem. So to reiterate my findings:

Problem:
Using ./gradlew clean build in console results in a successful build. The same happens with executing a IntelliJ Gradle-RunConfig for clean build but IntelliJ shows errors that do not end in a build failure.  There errors are thrown by us since we are testing the edge-cases of different features, but we we don't want them to be shown as errors in testing since this highlighting in tests should be reserved to test-failures..

What went wrong:
testLogging {
    events = events union setOf(
        TestLogEvent.FAILED,
        TestLogEvent.PASSED,
        TestLogEvent.SKIPPED,
        TestLogEvent.STANDARD_ERROR,
        TestLogEvent.STANDARD_OUT,
    )
    exceptionFormat = TestExceptionFormat.FULL
    showExceptions = true
    showCauses = true
    showStackTraces = true
}
We forgot about our own Logging: calling LOGGER.error("…", cause) in our StatusPage lets IntelliJ know there was an error.  Even though we handle it with a StatusPage and a corresponding call.respond later on. These errors are picked up by the IntelliJ-RunConfig and correctly displayed (i see why that feature makes sense. We just forgot about it.)

False-Leads:
The Debugger attached to the clean build run config does currently(?) not work with the kotest-test (tbh not sure if this has anything to do with kotest. And since we don't need this functionality that much no further support is needed). So when using breakpoints in our tests we never entered assertSoftly even though it was called correctly and no assertions failed.

Solution:
Don't log the cause or use different testLogging{} settings if you don't want those exceptions to be picked up by IntelliJ. And use the debugger for debugging single Integration-Tests and not the whole build-script since breakpoints are then correctly used. 

All problems for me and my team are solved. Thanks for your support.

0

请先登录再写评论。