Mr. Potociar,
Thanks again for the reply. I think I can understand that from your point
of view....
If you could humor me a bit further on this... What is the thoughts of
design here that Entity is not defined as an interface, but a class?
On Wed, Aug 26, 2015 at 9:35 AM Marek Potociar <marek.potociar_at_oracle.com>
wrote:
> 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> 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>
>> 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 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.
>>>
>>>
>