Testing obsolete interfaces

[Jan Hudec]

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.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060510/84b792b6/attachment.pgp