Testing obsolete interfaces

[Robert Collins]

On Wed, 2006-05-10 at 10:44 +0200, Jan Hudec wrote:
> On Wed, May 10, 2006 at 17:37:09 +1000, Robert Collins wrote:
> > On Tue, 2006-05-09 at 22:32 +0200, Jan Hudec wrote:
> > > On Tue, May 09, 2006 at 16:11:08 -0400, Aaron Bentley wrote:
> > > > Jan Hudec wrote:
> > > > > Hello,
> > > > > 
> > > > > The test suite prints all deprecation warnings on the error output. But isn't
> > > > > it supposed to test deprecated interfaces as long as they are kept around?
> > > > 
> > > > Whenever an interface becomes deprecated, none of the core code should
> > > > use it.  Printing deprecation warnings during test runs is a good way to
> > > > catch that when it does happen.
> > > > 
> > > > It's hard to distinguish between tests of deprecated functions and tests
> > > > of undeprecated functions that happen to call deprecated functions,
> > > > which means we're getting error output even for deprecations warnings we
> > > > expect.
> > > > 
> > > > Perhaps we need a decorator to suppress expected deprecations warnings
> > > > for test cases that exercise deprecated interfaces.
> > > 
> > > Another option, given the fact that the decorator always takes **kwargs,
> > > would be to implement a TEST=True extra parameter, that the decorator would
> > > remove and skip the warning if it's present... That way the tests of
> > > deprecated interfaces would be explicitly marked. Disadvantage of decorators
> > > is, that some testcases are quite long, so they may call some deprecated
> > > functions on purpose and others in error.
> > 
> > Heres a different perspective on this ... what about such a deprecated
> > function do we want to test ? The easiest way to ensure a deprecated
> > function is tested is to have it forward trivially to a supported
> > function. That function is presumably more generic/flexible and the
> > reason for the deprecated.
> 
> When that function is more generic, it may likely have completely
> different arguments -- in which case the forwarder has to convert them
> and that conversion has to be tested.
> 
> Also, maybe even more importantly, the tests for the old interface can
> be used to ensure the new interface is actually able to do all that the
> old interface was used for.
> 
> > In the case where we are removing functionality completely - deprecating
> > something we're going to stop supporting, then I think there is a still
> > a strong argument for separating the deprecated api and the tested
> > functionality.
> 
> I still don't think we want the deprecated api to bitrot before it's
> removed.

I think thats a judgement call that can be made for each api. So far, my
approach when deprecating an api has been to:
 * test and write the new functionality
 * forward the old functionality without deprecation
 * deprecate the old functionality
 * update the callers inside the codebase to use the new functionality.
 * remove tests for the old api : api stability in the new one prevents
   bitrot, and tests on the new one test the functionality.

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060510/7f09128b/attachment.pgp