[rfc][icedtea-web] TeeOutputStream Dependency Fix

[Omair Majid]

* 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?

> 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?

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

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".

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681