[rfc][icedtea-web] TeeOutputStream Dependency Fix

[Jacob Wisor]

On 09/09/2014 05:39 PM, Omair Majid wrote:
> * Jiri Vanek <jvanek at redhat.com> [2014-09-09 11:26]:
>> But there are cases, where is better to test the final method doing the real work.
>> In such case, it stops to be private and changes to package private.
>
> What's wrong about using a package-private method for this case?

Well yes, this is a possible approach. But, it has the side effect that you have 
to keep those methods in application code just for the purpose of testing. IMHO 
this makes a mess out of the beauty of clean application code. And then, there 
is always the risk of unwillingly introducing potential security holes as 
attackers may be able to exploit exactly the same methods which have been 
provided for testing only. I think that there is a lot more danger in 
unwittingly introducing side effects into "testing members" than the benefits 
they may offer just for the purpose of tests.

My philosophy actually is to have no code (or as little as possible) which bears 
no functionality for the application in production code. This keeps you safe and 
clean.

>> So I have started to incline to solution, where each
>>
>> public class ClassInITW
>>
>> have its
>>
>> public class TestClass extends Test
>>
>> in tests folder, which contains
>>
>> private class TestableClassInITW extends ClassInITW
>>
>> which is redeclaring all private such private methods, by theirs
>> accessible siblings, calliung its super by reflection. And the tests
>> are then run above tis artificial extension.
>>
>> What do you think?
>
> I don't know, this is not really testing the same method anymore. In
> fact, it's relying on the reflective testing code to be correct. For
> example, what if you make a mistake in the reflection code and call a
> method that looks really similar to another method?

Making mistakes applies to any code, application code as well as in test code. 
So this argument is actually invalid.

> It also seems much more complicated than marking a package as for
> "testing" only using comments and/or annotations and/or package-private
> marker.

Yes, is may be a little bit more complicated, but only just a bit. However, I do 
not accept the premise that just because human beings tend to be lazy, we should 
lower the standards for the our quality of work. ;-)

> This article mentions some alternatives and their pros and cons.
> http://www.artima.com/suiterunner/private.html
>
> These posts may also give you some costs and benefits of some
> possible approaches:
> http://stackoverflow.com/questions/34571/how-to-test-a-class-that-has-private-methods-fields-or-inner-classes
> http://programmers.stackexchange.com/questions/100959/how-do-you-unit-test-private-methods
>
> The overwhelming opinion seems to be "don't do it; test public
> interfaces only".

And, this is true. However, as already mentioned in another posting, testing 
public member is sometimes not enough.

Regards,
Jacob