Thoughts on Behavioral Testing

I'm kind of amazed with the fact that we define functions or methods as the "behavior" that an object exhibits, but when we test we only care about the outcome of that behavior.

If we have a car object with a driveHome() behavior, we only care that when the function is over we've asserted ourselves into the testing easy chair. Nevermind the fact that on the driveHome() we also errand.stopAtMarket(), errand.mailBills() and friends.visit( "Bob" ), which took too much time and delivered us home too late for our favorite show.

Behavioral mock objects are just one way to be sure that is DOING what you expect it to do, not just RETURNING what you expect.

Comments
bavads's Gravatar Isnt behavior better tested without mocking and the responsibility for validating the alogorithm better done via a mock framework? car.driveHome() is a unit of work and so is errand.stopAtMarket(). Combining these two in a scenario which is likely how the app would be used, isnt it best left for testing via an automated tool without the mock object??

Would like to hear your thoughts on this...
# Posted By bavads | 7/23/09 3:39 PM
Michael Steele's Gravatar @bevads,

You bring up a good point that people tend to miss when talking about behavioral mocks vs. behavioral testing. Behavioral mocks allow you to test the behavior of a method, not an entire process which you are describing.

If you have a service object called MyDay, and one of the functions is MyDay.goHome() which calls your errand.stopAtMarket() and then car.driveHome() methods, behavioral mocks would allow you to 1) mock the errand and car components so they don't violate one of the tenets of unit testing and go outside the tested class boundary 2) allow you to verify that those methods were in fact called from your goHome() method.
# Posted By Michael Steele | 8/14/09 7:59 PM
BlogCFC was created by Raymond Camden. This blog is running version 5.5.006. | Protected by Akismet | Blog with WordPress