Hi Fred, In this case, the "production code used for testing" is simply a ctor parameter that allows us to specify a mocked up URLConnectionFactory to be used in the unit test, instead of a real URLConnectionFactory that would obviously go away and create real HttpURLConnections, which we clearly do not want to do in a unit test.
In order for this ctor parameter to take effect, we also need to suppress the creation of the real URLConnectionFactory, which is normally done *post*-construction after the Conduit's config has been retrieved. The reason for this is that the presence of a SSLClientPolicy in config determines whether a Http*s*URLConnectionFactory is needed. Hence the "if statement" Polar refers to. So its not a case of extra code inserted to get the coverage to 100% (which is a bit of an unrealistic goal anyway, if we had 80% everywhere we'd be doing very well and I'd be delighted). Instead it's a trivial bit of code required to allow the HTTPConduit be tested in isolation. BTW speaking of testing, there doesn't seem to be any tests at all in Polar's TrustDecider patch. A unit test (possibly extending the existing HTTPConduitTest) is probably the least required. Cheers, Eoghan > -----Original Message----- > From: Fred Dushin [mailto:[EMAIL PROTECTED] > Sent: 21 March 2007 00:34 > To: [email protected] > Subject: Re: CXF-438 Patch; HTTP(S) Trust Decision > > I think it's fairly a defensible claim that having logic in > production code that is only used for testing purposes is bad > practice. > > If you need to hit 100% cvg and can't do it in a unit test, > then consider using a system test, instead. > > -Fred > > On Mar 20, 2007, at 2:23 PM, Polar Humenn wrote: > > > Well, I don't understand why we have *if* statements in the > code just > > to support the testing of the code. But maybe I can consider it > > "instrumentation". However, in any case, this explicit use of it > > should be documented up the wazzzo to prevent the "Huh??? what is > > *this* used for?" that wastes time in discovery. > >
