Thank you both. I'll dig into DefaultServer and copy what I need.
It helps to see that the Undertow tests on GitHub rely on a
third-party library's request/response API. That makes a lot of
sense, and I'm not sure why I thought it would be good idea to do
On Tue, Aug 8, 2017 at 3:58 PM, Stuart Douglas <sdouglas(a)redhat.com> wrote:
Note that DefaultServer is not a supported API as it is part of the
Undertow test suite, however it is unlikely to change much (I would
actually recommend just copying the class and deleting what you don't
I would definitely recommend testing by setting up a server and
testing using real HTTP requests. The overhead should be minimal, and
it makes the test much more realistic.
On Wed, Aug 9, 2017 at 12:41 AM, Tomaž Cerar <tomaz.cerar(a)gmail.com> wrote:
> You could use DefaultServer junit runner for your tests.
> Same "framework" that undertow tests are written with.
> for example see
> or pretty much any other test.
> On Tue, Aug 8, 2017 at 3:10 PM, Michael Hixson <michael.hixson(a)gmail.com>
>> I want to write junit tests for my application's HttpHandlers and I'm
>> wondering what the best way to simulate a request/response exchange
>> is. How do other people go about this?
>> My first thought was that I want to somehow:
>> 1) Build up a valid HttpServerExchange object to represent my incoming
>> request (likely the HTTP method, request URI, HTTP headers, and
>> request entity/body would vary from test to test)
>> 2) Instantiate my HttpHandler directly, and invoke its handleRequest
>> method directly
>> 3) Obtain a CompletableFuture that will complete when the exchange
>> completes (possibly by adding an
>> io.undertow.server.ExchangeCompletionListener to my exchange)
>> 4) Verify the contents of the response (possibly by examining the
>> HttpServerExchange object and by using an
>> io.undertow.conduits.StoredResponseStreamSinkConduit to record the
>> response entity)
>> This would all happen without creating an Undertow instance or binding
>> to any ports.
>> I started writing my own mock request/response library classes and
>> they're getting complicated enough that I'd rather reuse someone
>> else's work here if possible.
>> Maybe I'm going down the wrong path... I could create an Undertow
>> server instance and use something like a Jersey client to make actual
>> HTTP requests. Is that what other people do in their tests?
>> undertow-dev mailing list
> undertow-dev mailing list