On Jun 3, 8:50 pm, Ben Finney <[EMAIL PROTECTED]> wrote: > alex23 <[EMAIL PROTECTED]> writes: > > So the basic answers I'm seeing that "do just fine" are: > > > 1. Don't test private functions. > > 2. Add functionality _to_ the private functions for testing. > > 3. Change the interface for the purpose of testing. > > > All of which seem exceptionally inefficient and run counter to the > > whole purpose of unit testing. > > It seems you have a different idea of what unit testing is for from > me. > > Isn't the entire point of encapsulation to separate internal > components from the external interface? > > Why would a unit test, the whole purpose of which is to assert some > aspect of the external behaviour of the unit of code, care about how > that code unit is implemented internally? > > If changing the internal, encapsulated components of a unit causes its > external behaviour to change, that's a bug; either in the change made > (it shouldn't have altered the external behaviour), or in the unit > test asserting the wrong thing (it shouldn't be asserting anything > about internal state of the code). > > -- > \ “Try to become not a man of success, but try rather to become | > `\ a man of value.” —Albert Einstein | > _o__) | > Ben Finney
Thank you. Let me just add that, as I said before, I think "private" data (if it were added to Python) should be accessible through some sort of "indirect" mechanism akin to the double-leading-underscore rule. Then, even if it *is* needed for unit testing, it can be accessed. As for unit testing in C++, Java, and Ada, I confess I know nothing about it, but I assume it gets done. Considering that Ada is used to manage and control fighter jets, cruise missiles, and nuclear arsenals, let's hope it gets done right. -- http://mail.python.org/mailman/listinfo/python-list
