On Oct 17, 2015, at 12:43 PM, Jason T. Greene
<jason.greene(a)redhat.com> wrote:
Sorry for the delay. A number of us were traveling when you sent it.
The reason the class is final is just following the common practice of explicitly
disallowing inheritance unless the class is explicitly designed for it. The rationale
behind the practice is that a class that allows inheritance essentially has a fixed
implementation that can not evolve without potentially breaking compatibility.
Additionally if the class has concurrency behavior, inheritance that is not designed
around an explicit synchronization contract can lead to all kinds of bugs.
If you do want to use mock testing, there are frameworks like easymock which can generate
proxies for you, and your test code stays quite clean.
> On Oct 17, 2015, at 9:40 AM, Greg Hellings <greg.hellings(a)gmail.com> wrote:
>
> Ping.
>
> --Greg
>
>> On Oct 8, 2015 11:41 AM, "Greg Hellings"
<greg.hellings(a)gmail.com> wrote:
>> I'm trying to mock out the HttpServerExchange object in my tests, but
>> I apparently cannot do so because the class is declared final. Why is
>> it final? Does that give Undertow anything beneficial?
>>
>> If there's good reason to not remove the final, I can just wrap the
>> object in a proxy class that's not final, but I'd rather not do that
>> just to get around limitations in mocking. Another alternative would
>> be for me to skip unit tests on the handler methods and leverage
>> integration tests.But there are sometimes bits of logic in the handler
>> that I want to Unit Test directly.
>>
>> Any help would be appreciated.
>>
>> --Greg
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/undertow-dev
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev