I’m sorry, but I do not have any intention to consider loosening of the API contract just to support test mocking.
Again, I’m sorry, but no.
Marek
> On 21 Aug 2015, at 18:18, Qingtian Wang <wqt.net_at_gmail.com> wrote:
>
> Actually, there may be a compromise here:
>
> All I want is for the "final" to be removed. That way, I still can not subclass it given the private constructors and all that - that seams to address your concern of me doing "bad things" by subclassing. However, with the "final" gone, I will be able to "mock" to, using some mocking tool, like this:
>
> Entity mockEntity = mock(Entity.class);
> when(mockEntity.getEntity()).thenReturn(someMuliPartObjectSetupForTestingPurpose); // this is only possible without the "final" mark
>
> Again, I still can't subclass it even without the "final" mark; but i will able to "mock" it.
>
>
>
> On Fri, Aug 21, 2015 at 10:43 AM Qingtian Wang <wqt.net_at_gmail.com <mailto:wqt.net_at_gmail.com>> wrote:
> The point here is hard to "mock" (in which you'd set up verify/check/assert), not hard to "stub/generate/instantiate"(that is easy either with the current static factory methods, or with Matchers such as the one used in my example).
>
> As per the analogy to String, that is a bit far fetched IMO. Conceptually, String's representing data structure is simpler - mainly just its "value", whereas Entity includes data structure that encapsulates HTTP constructs which can be rather involved. Technically, Entity has a long way to go before getting to String's status: at least it should have things like "equalIgnoreAnnotations()", "equalIgnoreLocales()", and all kinds of constructors like String has, in addition to just the static factory methods currently.
>
> Bloch talks about the non-extendable drawback of having only static factory methods. IMO this case really falls into the drawback category instead of "blessing in disguise" - i am not trying to subclass and change Entity's behavior in my source code; rather i am just trying "mock" it such that i can test i am instantiating the Entity correctly, ex. by passing in the right data as the right parameters for the multiPart contained in the Entity.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Aug 21, 2015, 04:19 Marek Potociar <marek.potociar_at_oracle.com <mailto:marek.potociar_at_oracle.com>> wrote:
> You can come up with an entity generating code. Esp. for Entity it should be simple to implement. The arguments that you provide do not justify your requirement to make Entity non-final. You could as well argue for making String non-final… It just makes little sense IMO as problems would greatly outweigh any potential benefits.
>
> Marek
>
> > On 20 Aug 2015, at 21:49, wqt.net_at_gmail.com <mailto:wqt.net_at_gmail.com> wrote:
> >
> > Another clarification is that I have mixed up the terms of "stub" and
> > "mock" from the get go of my question: I guess what i am wanting to do
> > here is to "mock" (with check/verify/assert...) the Entity class, not
> > just to "stub" it.
>