[MERGE] Deprecate old fns that use InventoryEntry methods that ought to go
robertc at robertcollins.net
Thu Jul 19 08:42:38 BST 2007
On Thu, 2007-07-19 at 17:31 +1000, Ian Clatworthy wrote:
> John Arbash Meinel wrote:
> > Oh, we should make sure there is a test that it is deprecated... It
> > seems unfortunate that we have no test code exercising this already that
> > you can just switch to 'self.callDeprecated(change_entry)'
> Are you saying that every time we ever deprecate something, we should
> have a test that it is deprecated? I agree that's appropriate in certain
> cases but, as a blanket rule, it sounds a little excessive to me. I
> don't think that's really adding value, is it? Once I delete the code, I
> don't expect a test confirming that it no longer exists to stretch the
> analogy further.
> FWIW, we have 70+ deprecated symbols in the code base and very few tests
> (bar the generic ones) along these lines. I'm no TDD expert. I'd add it
> if you or anyone else feels strongly about it being the right thing to
> do. But it feels like I'm being asked to introduce a call to be piece of
> code when there are zero other known calls to that code in the universe
> and I want the code nuked at the earliest legal point in time I can.
If you delete a method, then sure, no test is ok. Though when you delete
something from an interface, having a test that there is no symbol may
be very useful to plugin writers.
Deprecated methods are still potentially used by plugins; we should make
sure they do not decay between deprecation and removal. So I think
requiring a test is not too aggressive, rather just sound caution.
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070719/d946048c/attachment.pgp
More information about the bazaar