If you separate your business logic from your data access logic, the last thing you want to do is make your business logic unit tests reliant on the database.  This is normally not a big deal: retrieve the data, store it in an array and pass it off to the class with the business logic.  Mocking the data for the unit test simply requires you to hardcode from array information in the test.  However, I recently ran into a case where I wanted to pass Zend_Db_Table_Row and Zend_Db_Table_Row objects to the business logic and mocking them was not so easy.

I was writing some code today and not using Test-Driven development.  The reason was that I did not have a good understanding of what I was writing, so I decided to write some of the guts before writing the tests.  In the process of writing the guts, I recognized that I was paying very close attention to how I was going to later test each of the methods I was writing. I was paying especially close attention to the Law of Demeter.   The idea behind the Law of Demeter is to keep units of code distinct from one another. So how did this relate to my code?  To put it simply, my business logic methods did not use get methods.