search

uber / tchannel-java

A Java implementation of the TChannel protocol.
MIT License
134 stars 67 forks source link

final Classes prevent mocking or subclassing #185

Closed achals closed 3 years ago

achals commented 6 years ago

I'm trying to integrate tchannel-java into an application, injecting the SubChannel into a Class to interact with another tchannel service.

But, there's effectively no way for me to test this class - I can't mock final classes, or make my own in-memory implementation of the SubChannel class.

I tried creating a non-final Wrapper for SubChannel, only exposing the relevant methods I intend to use, and a delegating to the actual SubChannel, but that's a rabbit hole since TFuture, ThriftResponse are all final.

I propose making all these class non-final - it would be a backwards compatible change, allow end users to integrate with the libraries with tests for their logic, and let users customize the implementations as needed.

jinscript commented 6 years ago

This might help? https://github.com/powermock/powermock/wiki/MockFinal

achals commented 6 years ago

Yes, that would have been great if we didn't have a way of changing the underlying library - do you think Powermock works better than just removing the finals, generally?

jinscript commented 6 years ago

Yeah. We used to use PowerMock and Mockito together. Each of them cover some cases. You should be able to test almost all cases with one of them.

alshopov commented 6 years ago

PowerMock for the win. Do not forget to use the proper runner so that the classes can be mocked.