I think it would be better as a different repo, so it can have its own
release cycle. We can't really use it in the Undertow test suite
itself, due to dependency issues (the runner needs to depend on core,
and core needs to depend on the runner. We could split the tests into
a different modules but that is a pain because then you need to build
multiple modules to test changes).
On Fri, Feb 3, 2017 at 3:57 AM, Bill O'Neil <bill(a)dartalley.com> wrote:
Just to follow up on this would it need a separate git repo or could
be a new maven sub project?
I don't know much about extending JUnit runners but it sounds like the
DefaultServer class can be renamed to UndertowRunner and moved to a new sub
project. Each other project could then add it as a test dependency and
update imports accordingly.
Is that all that would be required? Maybe it could be split up a bit or move
more testing related utils as well.
On Mon, Jan 16, 2017 at 8:59 PM, Bill O'Neil <bill(a)dartalley.com> wrote:
> Whatever you think is best. I'm fine following Steve's approach. Undertow
> starts up and shuts down pretty quick.
> On Sun, Jan 15, 2017 at 5:32 PM, Stuart Douglas <sdouglas(a)redhat.com>
>> We do publish tests-jars, so you can actually use DefaultServer,
>> however I agree that this is not really ideal.
>> I think the ideal solution would be to take the core functionality
>> from DefaultServer and create a new repo (undertow-test-runner) and
>> create some kind of UndertowRunner class that is based on
>> DefaultServer. Does this sound reasonable?
>> On Sun, Jan 15, 2017 at 7:22 AM, Bill O'Neil <bill(a)dartalley.com>
>> > Hello,
>> > How would you recommend testing custom HttpHanders? The DefaultServer
>> > class
>> > in core part of the test code so it is not included in the jar for
>> > reuse.
>> > Would it be reasonable to pull testing utils into their own project so
>> > it
>> > can be reused? Or would you recommend just mocking a HttpServerExchange
>> > and
>> > passing that to the HttpHandler?
>> > Thanks,
>> > Bill
>> > _______________________________________________
>> > undertow-dev mailing list
>> > undertow-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/undertow-dev