Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 543 posts at DZone. You can read more from them at their website. View Full User Profile

OOP: Behavioural and Structural Constraints

  • submit to reddit

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:

Behavioural constraints limit the way object state changes may occur

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

  • Informative – a message telling an object about something that happened in the past.
  • Imperative – a message telling an object to take some action on itself.

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:

Structural constraints limit the way objects associate with each other, that is, they restrict object state.

This seems close to an interrogative message:

  • Interrogative – a message asking an object to reveal something about itself.

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:

  • It ensures we're testing something useful otherwise we might be writing tests on our code for a scenario that will never happen.
  • We have a better idea of when we've finished writing our tests since we know when we've tested all the behaviour.
Published at DZone with permission of Mark Needham, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



andy darlow replied on Sat, 2010/01/02 - 8:38pm

Hi Mark

I think that its good to define where to test. I do think that imperative/informational is too broad though. If you think about it, imperative methods could be simple set methods and may be unimporant to testing the behavour (but needed for the GUI, say). I think that you've got to use your common sense and test methods that relate to solving the business problem. Sorry, I know that it's vague but I think it makes sense. I would recommend to test too much than too little.

As for structural constraints, these may be broken by imperative methods.

e.g. calling: team.injured(jim)

may throw a InsufficientTeamException to specify that you don't have enough players to play the game now that jim is injured.

Thus, I think that structure and interrogative methods are not neccesarily related; you may not have any interrogative methods in a class but the class may have structural constraints. You can test the constraints in this case via the invalid states. Again, it's down to the writing the testing against the requirements for that class.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.