Improve Integration-Tests

Description

The integration-tests could be modernized

Replace Apache HttpComponents with Jetty HttpClient

  • Apache HttpComponents is not provided as OSGi bundles, whereas Jetty HttpClient is

  • Jetty provides a much more concise API

Abstract URL-testing behind a fluent and descriptive API

  • Describe the what and not the how

  • Support async, authentication, post, timeout, logging

Make use of Java 8 features

  • Lambda-Expression where applicable

Environment

None

Activity

Show:
Achim Nierbeck
April 28, 2016, 7:53 PM

actually running the tests a second time, everything is clean ...

Marc Schlegel
April 28, 2016, 8:47 PM

That fits my observations as well...

It seems to me that the webcontainer is just not done internally setting up the application(s). Maybe the webcontainers(s) offer some API to check that the deployment has been completed (the WebEvent.DEPLOYED in Pax-Web might be fired to early).
I do not understand why this is not a problem with the old TestClient. The only reason I can think of is that the old impl is gathering some state since the instance is bound to a ITestBase for the whole test.
Since all tests have been abstracted now, it would be possible to bring the Apache HttpComponents TestClient back. Though I would prefer to stick with Jetty since it is much easier to digest whats happening.

Achim Nierbeck
April 28, 2016, 8:53 PM
Edited

don't think we need to switch back.
actually regarding the karaf whiteboard test, this is a race condition of the blueprint configuration. If the Filter is registered beforehand of the servlet this'll happen.

Marc Schlegel
May 1, 2016, 6:31 AM
Edited

I have increased the timeout for the JettyClient to 30 seconds after I figured out that the Apache HttpComponents blocks indefinately when no explicit timeout has been set.

— One can ensure the connection manager does not block indefinitely in the connection request operation by setting 'http.conn-manager.timeout' to a positive value.

This could explain why tests are failing unpreditable in Jenkins with timeouts that are running in current master.

EDIT: well, this didn't work. Even worse, the failed tests have increased by 3. I've resetted the branch to the state before my change

Marc Schlegel
August 10, 2016, 9:50 PM

Failing tests have been caused by the name used for the jenkins-job. Whitespaces can wreak havoc in some plugins.

Final code-cleanup has been performed, now that all tests are stable with the new API.

Note: once JUnit 5 is out, the custom assertion classes can probably be removed because JUnit 5 will add group-assertions.

Assignee

Marc Schlegel

Reporter

Marc Schlegel

Labels

None

Components

Fix versions

Affects versions

Priority

Minor
Configure