Yang Paulex wrote: > 2007/7/5, Alexei Zakharov <[EMAIL PROTECTED]>: >>> But I think the persistent delegate mechanism are very similar >>> with serialization, on which we need to be compatible with other >>> Java SE implementation, so it makes sense to make them the API >>> tests which pass on RI. Did I miss >> something? >> >> Yes, we need to be compatible with other implementations when we are >> talking about public API. We also should be able to read files >> produced by XMLEncoders from other implementations and do our best to >> make sure our XMLEncoder produces valid artifacts that can be red by >> other XMLDecoders. > > Agreed. > > At the same time I don't see any problems with having implementation >> specific tests. They check the behavior of our persistence delegates >> directly via calling their protected methods and without dealing with >> complex logic of (XML)Encoder / (XML)Decoder. And they won't pass on >> RI at least because RI uses other class names for its persistence >> delegates. My understanding is that we should not try to enable these >> tests on RI since IMO this kind of efforts could be treated as a >> reverse engineering of internal RI classes. > > Agreed, sorry if I made confusion here, my point is API tests is necessary > especially on compatibility, and of course if the implementation specific > test can help to improve the coverage and then Harmony implementation > quality, there's no reason not to welcome :). > >> On the other hand, we can test persistence delegates logic indirectly >> using (XML)Encoder / (XML)Decoder. And we have a lot of this kind of >> tests in XMLEncoderTest and XMLDecoderTest. These tests are API tests >> indeed and IMO should be enabled on RI as well as on Harmony. > > Glad to hear this, thanks
Cool -- sounds like we were vehemently agreeing ;-) Regards, Tim
