Quote:
A lot of respectable people tell you if a test touched a database, it is not a unit test, but I tend to disagree
I think it depends on how you view "unit testing" fundementally. Personally I see it as being different from BDD (a discussion I had years ago with Maugrim can be found for greater detail) in that TDD is more focused on testing the state/result of a SUT, whereas BDD is more oriented towards testing behaviors of an object, not as much with the result or state.
If your doing BDD (or TDD if your die hard I suppose) you are probably far more focused on design and thus behaviors and so your models probably use that additional abstraction layers to decouple the model from a data source, mocking the data store objects and thus focusing more on the behavior of the model, as opposed to the returned results, which is the case in classic testing, as opposed to mockist testing:
http://martinfowler.com/articles/mocksArentStubs.htmlIf you are less concerned with design and perhaps implement your models with a crude interpretation of table data gateway (by this I mean manually constructing the SQL query in the model and passing it to a DB abstraction layer query/execute method) you are far more likely to see benefit in testing the state of the method, rather than it's behavior, as business logic, etc is probably a series of conditionals which use local variables and are impossible to set expectations for.
On the other hand, if you are really focused on keeping your design OO then you probaly use a few objects to abstract the domain layer into logical peices, such as validation objects, data mappers, logging, etc. You probably promote inversion of control religiously and can therefore `test`the behavior of methods more easily than you did testing `state` back when you practiced more traditional or classical TDD.
This has been a distinction for me between the two methodolgoies, other than simply saying
`Ìf you do TDD properly your already doing BDD` -- despite what the invetor Dave Astels says.

Cheers,
Alex