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

Reply via email to