A few months ago I wrote a post describing how we should test the behaviour of code rather than the implementation whereby we would write tests against the public API of an object rather than exposing other internal data of the object and testing against that directly.

While I still think this is a useful way of testing code I didn’t really have a good definition for what makes that a test of an object’s behaviour.

I’ve been reading through James Odell’s 'Advanced Object-Oriented Analysis and Design Using UML' and he describes it like so:

In Meilir Page-Jones language I think this would describe informative and imperative messages:

Both of these types of messages change the state of the object so in C# or Java these would be the public methods on an object that clients interact with.

That seems to describe the way that we would test the object. These would be the methods that we’d call in our test.

Odell goes on to describe structural constraints:

This seems close to an interrogative message:

This would seem closer to the way that we would verify whether the object’s state changed as expected. We’re querying the object through the structural constraints that have been setup.

I can think of two main reasons why this approach is more effective than just testing directly against the internals of an object: