"German Morales" <germanmorales at delta-sys.com> wrote:
	Sometimes it happens to me that when writing Unit Tests I want to check
	internal state of an object, for example to see if it was affected by a
	message, and I end up writing (previously not needed) accessors for some
	of the instance variables.
	
This makes me feel rather queasy.  In my view, if I am supposed to be
testing behaviour, the object should be allowed to change its internal
state in any d---ed way it wants to.

Come to think of it, if an object can refer to another object which it
"owns" (created, and is the only holder of a reference to), just what
_is_ the internal state of the first object anyway.  If I have two
objects, A and B, and B holds all the actual internal state, and A's
only internal state is the reference to B, so that instead of
    "x := y + 1"
in A we find
    "myB x: myB y + 1"
then does A's "state" ever change?  If not, why not?  If so, how come
when it doesn't execute any assignment statements after setup?

	Unit tests should test as a black box only?

Not necessarily.

	If not, having public accesors is almost a need, at least the
	"get" ones.
	
Certainly not.  You can take advantage of Squeak's reflective
abilities.  White box testing of this kind is one of the very VERY
few excuses for using Object>>instVarNamed: .

Suppose you want to ensure that sending the #foo message to bar
doesn't change the instance variable !ugh and you do not otherwise
want to make "get the current value of !ugh" part of bar's public
interface.  So you do

    oldUgh := bar instVarNamed: #ugh.
    bar foo.
    newUgh := bar instVarNamed: #ugh.
    bar should: [newUgh == oldUgh].

Of course, #instVarNamed doesn't so much breach encapsulation as smash
it into kindling, blow it out of a cannon, and spit on the ashes.  The
only excuse for using it in white box testing is that white box tests
are _expected_ to break when you change the implementation of a class
anyway, and that doing this in the tests will improve encapsulation
elsewhere.