Did anything change from Ktor 0.9.5 -> 1.0.0-be...
# ktor
d
Did anything change from Ktor 0.9.5 -> 1.0.0-beta-3 for TestApplication tests? Suddenly all my tests fail after upgrading...
d
Do you have the stacktrace?
d
Everything returns null
Copy code
@Test
	fun testRequest() = withTestApplication(Application::appModule) {
		with(handleRequest(HttpMethod.Get, "/restrictions") {
			setBody(deviceRequestJson)
		}) {
			assertEquals(HttpStatusCode.OK, response.status())
			assertEquals(responseRestrictionsJson, response.content)
		}
	}
Copy code
java.lang.AssertionError: 
Expected :200 OK
Actual   :null
 <Click to see difference>


	at org.junit.Assert.fail(Assert.java:88)
	at org.junit.Assert.failNotEquals(Assert.java:834)
	at org.junit.Assert.assertEquals(Assert.java:118)
	at kotlin.test.junit.JUnitAsserter.assertEquals(JUnitSupport.kt:32)
....
It even skips any break point in the code... it only stops in the test code's break points.
But when I run the code and make requests with postman, it works...
d
uhm
have you done a
./gradlew clean
and stuff just in case?
in our codebase it seems to work
have you tried a smaller module?
d
I tried
clean
...
d
Have you tried the samples?
uhm, they are outdated, let me update them and check if the tests passes
maybe there is a feature interferrng or something causing the null in the tests? That’s why I would try to try with a smaller module to locate the problem
d
It's not that big (it's a microservice)... and it used to work in 0.9.5...
Just funny that I can't even breakpoint into the code... and why should null be returned everywhere? Should there be some kind of crash?
d
yeah, that’s strange
d
Or at least 404...
d
I’m trying the samples with beta-3 just in case there was a regression from beta-2
d
That's why I suspected that something changed..
d
Samples still work with beta-3
So your handler is not even called?
have you tried printing something?
d
Could try...
d
Breakpoints might be buggy in suspend code sometimes
d
In the route, doesn't print anything...
d
might be a bug (with something interferring) or something that changed but can’t tell exactly what. Try creating a test with a simpler module, with a hello world route, and then install the stuff you are using in your microservice to determine what’s causing that
d
Inside
routing { ... }
the `println()`s get called... maybe coroutines is swallowing an exception silently?
I haven't `launch`ed anything myself though...
d
maybe, the biggest change to ktor was structured coroutines but not sure if that could affect there in your case
d
Is there any easy way to catch a crash like that? Maybe installing a CoroutineExceptionHandler somewhere?
I do replace my whole repository with a mock one in my test runs... and it's a pretty different implementation.
A simple hello world path passes the test... it looks like something is crashing in the other route and I'm not getting any stack trace...
d
maybe you can try the status pages feature?
d
I have it installed, I should just try catching
Exception
? That could be an idea 🙂
d
try that and let’s see
d
Nope... tried
Copy code
exception<Exception> {
                println(it)
                call.respond(it)
            }
nothing, just nulls 😢
d
instead of Exception, Throwable?
but still that’s strange
not sure where is that swallowed
so you think it is swallowe at the routing block? or inside a route?
d
throwing from a route does print a stack trace even without the StatusPage... I think it has to do with my Kodein setup... I'll check that out. Funny that this is happening only after the upgrade.. but who knows?
d
Yeah that’s pretty funny. Let me know when you discover the cause
v
@dave08 do you use any cookie-handling in your testcases? Cookies are currently in beta-3 completely broken, see https://github.com/ktorio/ktor/pull/686
d
Nope.. thanks anyways, good to know.
m
Perhaps you have a mix of new and old dependency versions?
d
Nope, I used the Ktor generator IDEA plugin, and that makes a variable at the top of the gradle script for all Ktor component versions.
m
ok. maybe double check looking at
./gradlew dep
just to be sure?
d
Ok, I got it! I changed my route from GET to POST 🙈... But it's funny why the test engine gave me null for
status()
, shouldn't it have returned 404 or something (then I would have looked more closely at my routing...)?
m
When there's no route (or when you don't
respond
in a route), you get a null back in the test engine. I don't know why that is the case, but that's the current behavior
I agree that null isn't tremendously helpful
d
Maybe I should open an issue for this?
It's funny because the test engine has the same interceptor that sets any null status's to 404s...
m
Sure, I think we can come up with something better than null... might already be an issue open?
A
NoMatchingRoute
exception or something like that would be clearer
(and separately,
NoResponseWrittenException
?)
d
Here's the snippet:
Copy code
pipeline.intercept(EnginePipeline.Call) {
        try {
            call.application.execute(call)
            if (call.response.status() == null) {
                call.respond(HttpStatusCode.NotFound)
            }
In DefaultEnginePipeline.kt
m
interesting
d
According to that snippet, it should really be returning a 404, since TestApplication is derived from BaseApplicationEngine and that uses this pipeline...