PHP Developers Network

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 feel that it depends on what you are writing unit tests for.I think If you are unit testing a database adapter it should touch the database. What is devnet's thoughts?

In PHP it can be difficult to test a data accessor without touching the database (can't mock mysql_connect() etc) but that is the only valid unit test which is allowed to touch the DB in my opinion. For everything else, it can be mocked, even if all you do is simply create a wrapper for the mysql_* functions, and doing so specifically just for mocking/testing purposes is utterly justifiable and a must-do.

Is there a database mocking library? That is a good idea (wrapping the mysql functions, and an easy refactoring at that) but without touching the actual database how would you try to avoid over-specified software? I guess there is no utopia and an in memory database is the best you'll get huh?

My extension has a ton of dependencies on other code that would be impossible to mock (the API in question is not stable).

My other thing was, I always test my data mappers, which are in my model layer, and the tests run as part of my unit tests. From the reading I've been doing it made it seem like I'm doing something wrong.

I did however start putting my Test files in the same paths as my production code, which is probably another topic, but boy does that have a ton of benefits.

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.html

If 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

Well yeah, even if the logic is encapsulated in a DAO, you still gotta test the DAO, and the main confusion is wether that test is really a "unit" test or a functional test.

I have started using the When Then pattern

testWhenNoConfigurationThenThisHappens
testWhenThatConfigurationSomethingElseHappens
testWhenSomeOtherCOnfigurationTHatHappens
etc...