Thanks: El 04/09/13 05:01, Terry Reedy escribió:
I would expect that every account class has a transaction method. * If so, just call it, but assertIsNot(DebitAccount.transaction, AbstractAccount.transaction) for every subclass in your test suite. * If not, perhaps you need an abstract subclass TransAccount. Then use hasattr in production code and the isnot test in test code.
I would assume that you categorize this as a unit test problem, because you consider an Acount not implementing Transaction is a bug, right?
There are two occassions an account is intended not having Transaction function, both not test-related:
1. The acount doesn't offer this feature. e.g. Certificate of Deposit. This can be in TransAccount.
2. The 3rd-party account offer this feature but doesn't qualify the software's requirement, e.g. not returning the result in 3 seconds, and is avoided when planning the deal (I am writing an auto-trade software). This case you cannot categorize those who can into TransAccount, beacause 1) that naming imply other accounts don't do transaction but they do, just not good enough; 2) when other accounts becomes good enough, the change (to inheritance) is a bit too invasive.
-- https://mail.python.org/mailman/listinfo/python-list