Javalin: Create a testing tool

[tipsy]

People all have their own way of integration-testing Javalin apps. Maybe we should create an official package with a http-client and a set of useful methods?

The main goal is enabling people (and the Javalin project itself), to setup simple tests like this:

@Test
fun `error-mapper works for 500`() = TestUtil.test { app, http ->
    app.get("/exception") { throw RuntimeException() }
    app.error(500) { ctx -> ctx.result("Custom 500 page") }
    assertThat(http.getBody("/exception")).isEqualTo("Custom 500 page")
}

[tipsy]

I'm too lazy.

[aaronpoweruser]

I would find this useful, your test use internal classes of javalin, so are hard to replicate.

[alexey-wg2]

I can take this :)

[oharaandrew314]

My maven knowledge isn't super robust, but I believe the project structure would have to change in order to have separate javalin and javalin-test modules.

javalin/
  src/
  pom.xml
  ...
javalin-test/
  src/
  pom.xml
  ...
pom.xml
...

Are you ok inuring the massive delta to support this? Or would you prefer putting the test module in a different repo? Or is there a better way I don't know of. Apache HttpClient has the structure I'm speaking of.

[oharaandrew314]

@tipsy, how would you like to proceed regarding my previous comment?

[tipsy]

@oharaandrew314 Sorry, I missed your comment somehow. I'm not really sure what @alexey-wg2 has in mind. If the tool includes a HTTP client, I think it should live in a separate repo and be published independently of Javalin.

[oharaandrew314]

@tipsy I've created a javalin-test repo, with artifacts provided by jitpack. It's almost identical to the internal test client.

If you'd like to take ownership of it, I can move it from Gitlab to Github, and change the CI from Gitlab to travis. Alternatively, I'm happy to maintain it myself, and can add a link to it in the javalin Readme.

[tipsy]

@oharaandrew314 It would be great if you could maintain it, but if it's going to be used in Javalin itself, then maybe it should live under the Javalin org? (https://github.com/javalin). Would also be nice if it could be published to Maven Central 🤔

Here's a not so fun fact: The tests in Javalin also use OkHttp (gzip tests) and java_websocket (...WebSocket tst). Should this tool aim to eliminate either OkHttp or Unirest (Unirest is abandoned) and only use 1 HTTP client, and should it add an abstraction layer for easier WebSocket testing?

[oharaandrew314]

@tipsy, I'm totally fine with cutting out unirest in favor of okhttp. It
looks like it has a socket API too, but my experience with them is limited,
so I wouldn't know what kind of abstraction layer would be helpful. It may
be best to omit socket support from the client until it can be done in a
"good" way. People can attach their own clients in the meantime.

You can go ahead and make the repo under the org. If you give me write
access, I'll move everything over.

On Sun., Jun. 30, 2019, 5:12 p.m. David, [e-mail] wrote:

@oharaandrew314 https://github.com/oharaandrew314 It would be great if
you could maintain it, but if it's going to be used in Javalin itself, then
maybe it should live under the Javalin org? (https://github.com/javalin).
Would also be nice if it could be published to Maven Central 🤔

Here's a not so fun fact: The tests in Javalin also use OkHttp (gzip
tests) and java_websocket (...WebSocket tst). Should this tool aim to
eliminate either OkHttp or Unirest (Unirest is abandoned) and only use 1
HTTP client, and should it add an abstraction layer for easier WebSocket
testing?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tipsy/javalin/issues/556?email_source=notifications&email_token=AAG2JSECFMQ6BAQNVPKVHGDP5EOSZA5CNFSM4HGWZS62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY4T3VA#issuecomment-507067860,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAG2JSGYUJGFUNU7TTSURDTP5EOSZANCNFSM4HGWZS6Q
.

[tipsy]

@oharaandrew314 I've created a repo and invited you. The abstraction layer for WebSocket is written into the WebSocket test in the repo, it's mainly wait-functions. Would be nice if the methods could be made blocking. I don't think it's required to use OkHttp for WebSockets, java_websocket should be fine.

[tipsy]

Unirest is back in active development: https://github.com/OpenUnirest/unirest-java, https://github.com/Kong/unirest-java

[tipsy]

They also have created their own testing tool now: https://github.com/Kong/unirest-java/issues/265

[oharaandrew314]

@tipsy, do you strongly prefer using Unirest instead of okhttp in javalin-test?

As for the proposed unirest testing lib you mentioned, how do you imagine it would be helpful?

[tipsy]

@tipsy, do you strongly prefer using Unirest instead of okhttp in javalin-test?

Not at all. While it looks like Unirest has been saved from abandonment now, okhttp is still a much stronger choice. I'm not a big fan of how clunky their API is, but for the purpose of this tool, that could be abstracted away.

As for the proposed unirest testing lib you mentioned, how do you imagine it would be helpful?

I'm not sure, I just included it for inspiration. They had a neat assert method on the response, we could do something similar.

[Alexey1Gavrilov]

Please have a look to a proposed changes to the Maven structure https://github.com/tipsy/javalin/pull/749

[tipsy]

@oharaandrew314 have you had a chance to check out the PR ?

[oharaandrew314]

@tipsy I agree it's probably best to include it as a submodule. I had some work in progress to incorporate Rest Assured into the test project, but I think it would be pretty simple to add it to the JUnit Rule if we desire.