(appologies for bad grammar, it is late for me)
I've attached a nice sized patch to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=271535 to add integration testing to the build.
The primary test being performed is for the RFC2616 validation that was previously in the jetty-server tests.
This patch adds a new top level tree called /tests/ .
I chose this structure as a way to put all of the testing specific artifacts into their own groupId (namespace) of org.eclipse.jetty.tests, which should reduce the pollution of the artifact space some.
Some highlights:
Internally, I have setup the /test-integration/ to load the server via the standard Jetty xml files, found in the /test-integration/src/test/resources/ folder.
The RFC2616 tests are performed with all 4 server connectors (BIO/NIO and HTTP/SSL).
There is a new HttpTesting object, which was inspired off of the HttpTester object in /test-jetty-servlet/ but beefed up to eliminate request/response pollution, add some junit-isms to assert state on the responses, and utilize the HttpGenerator and HttpParser more intelligently for pipelined requests.
There is a hardcoded STRICT boolean (set to false) that is being used to enable/disable strict RFC2616 testing. Some tests are known not to pass due to intentional decisions in Jetty under the guise of maximum compatibility (MSIE bugs) with regards to intentional deviation from the RFC2616 spec. Using the STRICT boolean, I was able to still code against the strict interpretation of RFC2616.
I welcome any feedback.
---
Joakim Erdfelt
joakim@...
